[wildfly-dev] Multi-release module JARs

[Brian Stansberry]

On Wed, Jun 10, 2020 at 5:09 PM David Lloyd <david.lloyd at redhat.com> wrote:

> On Wed, Jun 10, 2020 at 4:41 PM Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> >
> > Thanks for this thread, Paul.
> >
> > On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro <paul.ferraro at 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.)
>
> 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.
>

Thanks, David.

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

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200611/83504a0f/attachment.html