<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 5:10 PM David Lloyd &lt;<a href="mailto:david.lloyd@redhat.com">david.lloyd@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">On Wed, Jun 10, 2020 at 4:41 PM Brian Stansberry<br>
&lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Thanks for this thread, Paul.<br>
&gt;<br>
&gt; On Wed, Jun 10, 2020 at 3:31 PM Paul Ferraro &lt;<a href="mailto:paul.ferraro@redhat.com" target="_blank">paul.ferraro@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; In version 30 of jboss-parent-pom, David Lloyd added the ability to<br>
&gt;&gt; easily produce multi-release jars [1].  While several components<br>
&gt;&gt; consumed by WildFly currently produce multi-release jars (e.g.<br>
&gt;&gt; wildfly-common, Undertow, Infinispan, etc.), as far as I am aware,<br>
&gt;&gt; none of the modules in WildFly (or wf-core) do this.<br>
&gt;&gt;<br>
&gt;&gt; I recently created a pull request to WildFly [2] that ports a<br>
&gt;&gt; collection class from Undertow [3], which, when built using Java 9+,<br>
&gt;&gt; results in faster expiration scheduling for persistent HttpSessions<br>
&gt;&gt; and local @Stateful EJBs.  While the changes introduced in this PR are<br>
&gt;&gt; still compatible with JDK 8 [4], this optimization will not be<br>
&gt;&gt; available to users unless they build wildfly using JDK 9+ in order to<br>
&gt;&gt; produce the requisite multi-release jar for the<br>
&gt;&gt; wildfly-clustering-ee-cache module.<br>
&gt;&gt;<br>
&gt;&gt; What do people think about this?<br>
&gt;&gt;<br>
&gt;&gt; Is there any reason why we should *not* compile using JDK 11 when<br>
&gt;&gt; building releases (while still maintaining Java 8 source<br>
&gt;&gt; compatibility, of course)?<br>
&gt;<br>
&gt;<br>
&gt; 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.<br>
&gt;<br>
&gt; 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.)<br>
<br>
By adding an empty file named `build-test-java8` to each module<br>
directory, and by having JDK 8 present in the test environment (in<br>
addition to JDK 11), the modules will be tested with both JDK 8 and<br>
JDK 11 while being built.  It is necessary to pass in a property to<br>
Maven called `java8.home` pointing to the location of the JDK 8<br>
installation to make this work.</blockquote><div><br></div><div>Just a general note:</div><div>-Djava8.home=... is already passed on most of the JDK 11 jobs we have, if there are additional projects that need it added, feel free to ping me and I&#39;ll take care of it.</div><div><br></div><div>Ken</div><div><br></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">  Doing so is much faster (overall, in<br>
CPU-time) than having two completely separate CI jobs, one for 8 and<br>
one for 11, because even though the tests would run sequentially, the<br>
majority of the setup and build will be done only one time instead of<br>
twice.  It would somewhat increase wallclock time due to the<br>
sequential nature of testing with 8 and again with 11.<br>
<br>
&gt; 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.<br>
&gt;<br>
&gt; This isn&#39;t a showstopper kind of thing for me, it&#39;s just something to think about and make a conscious plan.<br>
<br>
-- <br>
- DML<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><br>
<br>
</blockquote></div></div>