WildFly Java 9 support & CI job

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

WildFly Java 9 support & CI job

Jaikiran Pai-2

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Tomaž Cerar-2

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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Jaikiran Pai-2
Hi Tomaz,

Thank you for the detailed explanation. I wasn't aware that it's this much more involved with switching to -target 9. I certainly need to catch up with these more frequent Java releases soon :)

-Jaikiran


On 07/03/18 3:05 PM, Tomaž Cerar 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Stuart Douglas
In reply to this post by Tomaž Cerar-2
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 <[hidden email]> 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Tomaž Cerar-2
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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 < [hidden email] >
> 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 < [hidden email] > 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: [hidden email]
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Stuart Douglas
In reply to this post by Tomaž Cerar-2


On Fri, Mar 9, 2018 at 10:46 AM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Tomaž Cerar-2
Hey,

I got it working locally, it needed only 2 testsuite classes changes to not use sun.* internal api.

Change is part of my JDK10/11 PR https://github.com/wildfly/wildfly/pull/10982

To enable it, just run on JDK9/10/11 and pass -Djdk-release=9/10/11
which will compile testsuite classes to selected release.

I've added it as optionally enabled profile as when you use it, pretty much everything fails ATM.
This way we can only have it on CI for time being.

--
tomaz


On Sun, Mar 11, 2018 at 10:37 PM, Stuart Douglas <[hidden email]> wrote:


On Fri, Mar 9, 2018 at 10:46 AM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: WildFly Java 9 support & CI job

Tomaž Cerar-2
is now running with -Djdk-release=10 which will compile testsuite with release=10
and should show up problems like this.

--
tomaz

On Mon, Mar 12, 2018 at 2:09 PM, Tomaž Cerar <[hidden email]> wrote:
Hey,

I got it working locally, it needed only 2 testsuite classes changes to not use sun.* internal api.

Change is part of my JDK10/11 PR https://github.com/wildfly/wildfly/pull/10982

To enable it, just run on JDK9/10/11 and pass -Djdk-release=9/10/11
which will compile testsuite classes to selected release.

I've added it as optionally enabled profile as when you use it, pretty much everything fails ATM.
This way we can only have it on CI for time being.

--
tomaz


On Sun, Mar 11, 2018 at 10:37 PM, Stuart Douglas <[hidden email]> wrote:


On Fri, Mar 9, 2018 at 10:46 AM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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: [hidden email]
Sent: sreda, 07. marec 2018 06:11
To: [hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev