<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks for this thread, Paul.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro &lt;<a href="mailto:paul.ferraro@redhat.com">paul.ferraro@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">One issue I can think of is CI. We&#39;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. </div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">The tests in the subsystems wouldn&#39;t run with JDK 8 unless we had separate jobs just for that purpose (which is no big deal.)</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">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.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">This isn&#39;t a showstopper kind of thing for me, it&#39;s just something to think about and make a conscious plan.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote><div><br></div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif">I don&#39;t.</div><div class="gmail_default" style="font-family:&quot;trebuchet ms&quot;,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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] <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><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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>