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

[Stuart Douglas]

On Fri, Mar 9, 2018 at 10:46 AM, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:

> 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.
>

This issue is not about module-info.class, the issue is that all JDK9
classes have their annotations ignored, which would be caught.

Stuart


>
> 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 <jai.forums2013 at gmail.com>
>>> *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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180312/aa200dc6/attachment.html