Could we look at making one or all of the test suite modules compile
using -target
9 ? This was the server is still built the same way, but it should pick up
issues like this in testing.
Stuart
On Wed, Mar 7, 2018 at 8:35 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
Hey Jaikiran,
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. Yet!
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 compatible.
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
https://issues.jboss.org/browse/SECURITY-986
https://issues.jboss.org/browse/SECURITY-985
https://issues.jboss.org/browse/ISPN-8844
https://issues.jboss.org/browse/AESH-458
https://issues.jboss.org/browse/AESH-457
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.
--
tomaz
*From: *Jaikiran Pai <jai.forums2013(a)gmail.com>
*Sent: *sreda, 07. marec 2018 06:11
*To: *wildfly-dev(a)lists.jboss.org
*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[1] and I *think* another user here in the
forum thread[2] 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 [3], 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 [4] 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)?
[1]
https://issues.jboss.org/browse/WFLY-9961
[2]
https://developer.jboss.org/thread/277401
[3]
https://ci.wildfly.org/viewType.html?buildTypeId=WF_
MasterLinuxJdk9&branch_WF=__all_branches__
[4]
http://repo1.maven.org/maven2/org/jboss/jboss-parent/25/
jboss-parent-25.pom
-Jaikiran
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev