[wildfly-dev] Multi-release module JARs

[Darran Lofthouse]

On Thu, Jun 11, 2020 at 9:08 AM Tristan Tarrant <ttarrant at redhat.com> wrote:

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

To add to this -release produces the correct bytecode, but -target does not
so it is important to use the correct one of these.


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

As we found out, such as preventing the use of new methods added to
SSLEngine and SSLSocket in the most recent Java 8 releases.


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

Let's not push it ;-) - we already know PicketBox and it's integration will
crumble when we get to that version ;-)


>
>
> 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 at redhat.com
> > <mailto: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.)
> >
> > 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/io/undertow/util/FastConcurrentDirectDeque.java
> >     [4] https://ci.wildfly.org/buildConfiguration/WFPR/207451
> >
> >     _______________________________________________
> >     wildfly-dev mailing list
> >     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200611/c4ba47c2/attachment-0001.html