<div dir="ltr"><div dir="ltr">On Thu, Jun 11, 2020 at 9:08 AM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I commented on GitHub, but probably this is more appropriate:<br>
<br>
I really so no point in building releases with JDK 8 any more:<br>
<br>
* Using the -release 8 compiler argument produces the correct bytecode <br>
and verifies JDK method signature compatibility similar to what animal <br>
sniffer did<br></blockquote><div><br></div><div>To add to this -release produces the correct bytecode, but -target does not so it is important to use the correct one of these.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* It acts as an obstacle to the usage of JDK-specific improvements<br></blockquote><div><br></div><div>As we found out, such as preventing the use of new methods added to SSLEngine and SSLSocket in the most recent Java 8 releases.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Raises awareness about incompatibilities that might happen with newer <br>
JDKs.<br>
<br>
I would even go as far as saying that you should build upstream <br>
nightlies with the latest stable JDK (14) even if it isn't an LTS just <br>
to validate that last statement.<br></blockquote><div><br></div><div>Let's not push it ;-) - we already know PicketBox and it's integration will crumble when we get to that version ;-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Tristan<br>
<br>
<br>
<br>
On 10/06/2020 23:39, Brian Stansberry wrote:<br>
> Thanks for this thread, Paul.<br>
> <br>
> On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro <<a href="mailto:paul.ferraro@redhat.com" target="_blank">paul.ferraro@redhat.com</a> <br>
> <mailto:<a href="mailto:paul.ferraro@redhat.com" target="_blank">paul.ferraro@redhat.com</a>>> wrote:<br>
> <br>
> In version 30 of jboss-parent-pom, David Lloyd added the ability to<br>
> easily produce multi-release jars [1]. While several components<br>
> consumed by WildFly currently produce multi-release jars (e.g.<br>
> wildfly-common, Undertow, Infinispan, etc.), as far as I am aware,<br>
> none of the modules in WildFly (or wf-core) do this.<br>
> <br>
> I recently created a pull request to WildFly [2] that ports a<br>
> collection class from Undertow [3], which, when built using Java 9+,<br>
> results in faster expiration scheduling for persistent HttpSessions<br>
> and local @Stateful EJBs. While the changes introduced in this PR are<br>
> still compatible with JDK 8 [4], this optimization will not be<br>
> available to users unless they build wildfly using JDK 9+ in order to<br>
> produce the requisite multi-release jar for the<br>
> wildfly-clustering-ee-cache module.<br>
> <br>
> What do people think about this?<br>
> <br>
> Is there any reason why we should *not* compile using JDK 11 when<br>
> building releases (while still maintaining Java 8 source<br>
> compatibility, of course)?<br>
> <br>
> <br>
> One issue I can think of is CI. We'd probably need to alter jobs to <br>
> build with JDK 11 and then test with JDK 8. I think our integration <br>
> testsuite runs for JDK 8 should be running a server built the way a <br>
> released server is built.<br>
> <br>
> The tests in the subsystems wouldn't run with JDK 8 unless we had <br>
> separate jobs just for that purpose (which is no big deal.)<br>
> <br>
> To be fair, our JDK 11 CI jobs are building with JDK 11 and then testing <br>
> that, and our releases are built with JDK 8. So the existence of a <br>
> mismatch is not new. My impression though is JDK 8 remains dominant, so <br>
> shifting the mismatch to the JDK 8 side is a concern.<br>
> <br>
> This isn't a showstopper kind of thing for me, it's just something to <br>
> think about and make a conscious plan.<br>
> <br>
> <br>
> Even if we continue to create releases using JDK 8 builds, does anyone<br>
> object to giving users the option to build WildFly with multi-release<br>
> module jars when compiling with a more recent JDK version?<br>
> <br>
> <br>
> I don't.<br>
> <br>
> <br>
> [1] <a href="https://issues.redhat.com/browse/WFLY-10178" rel="noreferrer" target="_blank">https://issues.redhat.com/browse/WFLY-10178</a><br>
> [2] <a href="https://github.com/wildfly/wildfly/pull/13334" rel="noreferrer" target="_blank">https://github.com/wildfly/wildfly/pull/13334</a><br>
> [3]<br>
> <a href="https://github.com/undertow-io/undertow/blob/master/core/src/main/java9/io/undertow/util/FastConcurrentDirectDeque.java" rel="noreferrer" target="_blank">https://github.com/undertow-io/undertow/blob/master/core/src/main/java9/io/undertow/util/FastConcurrentDirectDeque.java</a><br>
> [4] <a href="https://ci.wildfly.org/buildConfiguration/WFPR/207451" rel="noreferrer" target="_blank">https://ci.wildfly.org/buildConfiguration/WFPR/207451</a><br>
> <br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> <br>
> <br>
> <br>
> -- <br>
> Brian Stansberry<br>
> Manager, Senior Principal Software Engineer<br>
> Red Hat<br>
> <br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
> <br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div></div>