Thanks for this thread, Paul. On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: > > In version 30 of jboss-parent-pom, David Lloyd added the ability to > easily produce multi-release jars [1]. While several components > consumed by WildFly currently produce multi-release jars (e.g. > wildfly-common, Undertow, Infinispan, etc.), as far as I am aware, > none of the modules in WildFly (or wf-core) do this. > > I recently created a pull request to WildFly [2] that ports a > collection class from Undertow [3], which, when built using Java 9+, > results in faster expiration scheduling for persistent HttpSessions > and local @Stateful EJBs. While the changes introduced in this PR are > still compatible with JDK 8 [4], this optimization will not be > available to users unless they build wildfly using JDK 9+ in order to > produce the requisite multi-release jar for the > wildfly-clustering-ee-cache module. > > What do people think about this? > > Is there any reason why we should *not* compile using JDK 11 when > building releases (while still maintaining Java 8 source > compatibility, of course)? One issue I can think of is CI. We'd probably need to alter jobs to build with JDK 11 and then test with JDK 8. I think our integration testsuite runs for JDK 8 should be running a server built the way a released server is built. The tests in the subsystems wouldn't run with JDK 8 unless we had separate jobs just for that purpose (which is no big deal.)

To be fair, our JDK 11 CI jobs are building with JDK 11 and then testing that, and our releases are built with JDK 8. So the existence of a mismatch is not new. My impression though is JDK 8 remains dominant, so shifting the mismatch to the JDK 8 side is a concern. This isn't a showstopper kind of thing for me, it's just something to think about and make a conscious plan.

On Wed, Jun 10, 2020 at 4:41 PM Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > Thanks for this thread, Paul. > > On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: >> >> In version 30 of jboss-parent-pom, David Lloyd added the ability to >> easily produce multi-release jars [1]. While several components >> consumed by WildFly currently produce multi-release jars (e.g. >> wildfly-common, Undertow, Infinispan, etc.), as far as I am aware, >> none of the modules in WildFly (or wf-core) do this. >> >> I recently created a pull request to WildFly [2] that ports a >> collection class from Undertow [3], which, when built using Java 9+, >> results in faster expiration scheduling for persistent HttpSessions >> and local @Stateful EJBs. While the changes introduced in this PR are >> still compatible with JDK 8 [4], this optimization will not be >> available to users unless they build wildfly using JDK 9+ in order to >> produce the requisite multi-release jar for the >> wildfly-clustering-ee-cache module. >> >> What do people think about this? >> >> Is there any reason why we should *not* compile using JDK 11 when >> building releases (while still maintaining Java 8 source >> compatibility, of course)? > > > One issue I can think of is CI. We'd probably need to alter jobs to build with JDK 11 and then test with JDK 8. I think our integration testsuite runs for JDK 8 should be running a server built the way a released server is built. > > The tests in the subsystems wouldn't run with JDK 8 unless we had separate jobs just for that purpose (which is no big deal.) By adding an empty file named `build-test-java8` to each module directory, and by having JDK 8 present in the test environment (in addition to JDK 11), the modules will be tested with both JDK 8 and JDK 11 while being built. It is necessary to pass in a property to Maven called `java8.home` pointing to the location of the JDK 8 installation to make this work. Doing so is much faster (overall, in CPU-time) than having two completely separate CI jobs, one for 8 and one for 11, because even though the tests would run sequentially, the majority of the setup and build will be done only one time instead of twice. It would somewhat increase wallclock time due to the sequential nature of testing with 8 and again with 11.

> To be fair, our JDK 11 CI jobs are building with JDK 11 and then testing that, and our releases are built with JDK 8. So the existence of a mismatch is not new. My impression though is JDK 8 remains dominant, so shifting the mismatch to the JDK 8 side is a concern. > > This isn't a showstopper kind of thing for me, it's just something to think about and make a conscious plan. -- - DML

I commented on GitHub, but probably this is more appropriate: I really so no point in building releases with JDK 8 any more: * Using the -release 8 compiler argument produces the correct bytecode and verifies JDK method signature compatibility similar to what animal sniffer did

* It acts as an obstacle to the usage of JDK-specific improvements

* Raises awareness about incompatibilities that might happen with newer JDKs. I would even go as far as saying that you should build upstream nightlies with the latest stable JDK (14) even if it isn't an LTS just to validate that last statement.

Tristan On 10/06/2020 23:39, Brian Stansberry wrote: > Thanks for this thread, Paul. > > On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro <paul.ferraro(a)redhat.com > <mailto:paul.ferraro@redhat.com>> wrote: > > In version 30 of jboss-parent-pom, David Lloyd added the ability to > easily produce multi-release jars [1]. While several components > consumed by WildFly currently produce multi-release jars (e.g. > wildfly-common, Undertow, Infinispan, etc.), as far as I am aware, > none of the modules in WildFly (or wf-core) do this. > > I recently created a pull request to WildFly [2] that ports a > collection class from Undertow [3], which, when built using Java 9+, > results in faster expiration scheduling for persistent HttpSessions > and local @Stateful EJBs. While the changes introduced in this PR are > still compatible with JDK 8 [4], this optimization will not be > available to users unless they build wildfly using JDK 9+ in order to > produce the requisite multi-release jar for the > wildfly-clustering-ee-cache module. > > What do people think about this? > > Is there any reason why we should *not* compile using JDK 11 when > building releases (while still maintaining Java 8 source > compatibility, of course)? > > > One issue I can think of is CI. We'd probably need to alter jobs to > build with JDK 11 and then test with JDK 8. I think our integration > testsuite runs for JDK 8 should be running a server built the way a > released server is built. > > The tests in the subsystems wouldn't run with JDK 8 unless we had > separate jobs just for that purpose (which is no big deal.) > > To be fair, our JDK 11 CI jobs are building with JDK 11 and then testing > that, and our releases are built with JDK 8. So the existence of a > mismatch is not new. My impression though is JDK 8 remains dominant, so > shifting the mismatch to the JDK 8 side is a concern. > > This isn't a showstopper kind of thing for me, it's just something to > think about and make a conscious plan. > > > Even if we continue to create releases using JDK 8 builds, does anyone > object to giving users the option to build WildFly with multi-release > module jars when compiling with a more recent JDK version? > > > I don't. > > > [1] https://issues.redhat.com/browse/WFLY-10178 > [2] https://github.com/wildfly/wildfly/pull/13334 > [3] > https://github.com/undertow-io/undertow/blob/master/core/src/main/java9/i... > [4] https://ci.wildfly.org/buildConfiguration/WFPR/207451 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

In version 30 of jboss-parent-pom, David Lloyd added the ability to easily produce multi-release jars [1]. While several components consumed by WildFly currently produce multi-release jars (e.g. wildfly-common, Undertow, Infinispan, etc.), as far as I am aware, none of the modules in WildFly (or wf-core) do this. I recently created a pull request to WildFly [2] that ports a collection class from Undertow [3], which, when built using Java 9+, results in faster expiration scheduling for persistent HttpSessions and local @Stateful EJBs. While the changes introduced in this PR are still compatible with JDK 8 [4], this optimization will not be available to users unless they build wildfly using JDK 9+ in order to produce the requisite multi-release jar for the wildfly-clustering-ee-cache module. What do people think about this? Is there any reason why we should *not* compile using JDK 11 when building releases (while still maintaining Java 8 source compatibility, of course)? Even if we continue to create releases using JDK 8 builds, does anyone object to giving users the option to build WildFly with multi-release module jars when compiling with a more recent JDK version? [1] https://issues.redhat.com/browse/WFLY-10178 [2] https://github.com/wildfly/wildfly/pull/13334 [3] https://github.com/undertow-io/undertow/blob/master/core/src/main/java9/i... [4] https://ci.wildfly.org/buildConfiguration/WFPR/207451 _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev