yes there are known issues with Jandex and also with few proposed fixes but we didn’t
manage to get them merged and/or released.
When it comes to -source / -target 9 compiling there is a reason why we do not use it.
When one switches to compile for -target 9, whole behavior of compiler changes as result
we can no longer access non public classes or modules.
Unless we add module-info.java for problematic maven modules.
But adding module-info.java means all (maven) compile dependencies of said maven module
need to be jigsaw compatible, which at this point is not really there yet.
Currently we have to problematic modules that cause issues with this.
“cli” in wildfly-core, and “security” in wildfly repository.
Both of them have quite big dependency tree where many of its jars are not jigsaw
I do have working branch that has quite some work done on this subject, but until we get
dependencies fixed to not violate jigsaw rules, it cannot be completed.
Here is non complete list of Jira issues that track jigsaw problems in our dependencies
that prevent cli and security to be compiled with target = 9
So in short our support of JDK9/10 is currently scoped only to using it as runtime JDK of
the server. None of the jigsaw related features will work in deployments.
Said all that, jandex problem is real, we will fix it.
From: Jaikiran Pai
Sent: sreda, 07. marec 2018 06:11
Subject: [wildfly-dev] WildFly Java 9 support & CI job
It appears that the recent release of WildFly 12.0.0.Final has a major issue with Java 9
support for deployments. More specifically, if the application being deployed is compiled
using Java 9 JDK then the annotation processing (through Jandex) causes such classes to
skip the annotation indexing, effectively missing any annotation information present on
them. There's a JIRA for it here and I think another user here in the forum
thread is affected by the same issue. I see that Stuart is already upgrading Jandex
which includes a fix, so this mail isn't really about fixing this issue.
Given the ease with which this got reproduced and the fact that we missed it in our
regular integration job for Java 9 , I looked around to see why we couldn't catch
this earlier. It looks like the WildFly pom.xml uses org.jboss:jboss-parent:25  which
fixes the target class version of the compilation to 1.8. As a result, even though the CI
job uses Java 9 to compile the application sources (in test cases) it ends up with a class
version to Java 8 and that explains why these issues weren't caught earlier.
So would it be possible to have another variant of this CI job which passes Java 9 as the
target version for compiled sources, as a system property value (the pom.xml of
jboss-parent allows the value to be configured through properties)?