[wildfly-dev] WildFly Java 9 support & CI job

[Rostislav Svoboda]

+1 for some coverage on this.

I think running Quickstarts with -target 9 is good option too.
I'm looking into preparing matrix job to run it in our Jenkins.
Probably daily job for latest wf master + qs master.
and we need https://github.com/wildfly/wildfly-core/pull/3157 before we move on

Rostislav

----- Original Message -----
> I can take a look at it.
> As long as we don't use any non public app in tests suite, it should work.
> 
> But this still wouldn't catch issues like this, as we wouldn't not have
> deployments with module-info.class present.
> 
> But it would certainly have its benefits.
> 
> --
> Tomaž
> 
> On Fri, 9 Mar 2018 at 00:13, Stuart Douglas < stuart.w.douglas at gmail.com >
> wrote:
> 
> 
> 
> 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 at 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
> Sent: sreda, 07. marec 2018 06:11
> To: wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev