
<html><head></head><body>Hi Alan, hi Remi,<br><br>Of course the MR-JAR is only half of the story. Magically it will work (and with java 20 EA it just logs a warning and uses the old impl).<br><br>It works like this:<br><br>We compile the classes using a separate Geadle source set using toolkit auto-provisioning. There's also some SPI like factory/provider API on our side for IndexInputs. Class names are also different to the old code (IndexInputs, Provider), so actually the MR-JAR is not needed. Theoretically we could package them into the main part of JAR file compiled against Java 11. But this would complicate build and IDEs could stumble on this. So the additional new classes are isolated in MR-JAR.<br><br>The service provider like code tries to instantiate the MemoryMappingIndexInputProvider using a Lookup and method handle (no reflection as the class is PKG protected, so with lookup works without accessible hacks). On Java before 19 it will fail to load the class (not found due to MR-JAR). On Java 19 or later it will find the class and tries to load it. As it is marked as "using preview", without preview enabled it will throw classformat error. When preview is enabled, it succeeds to load (voila). If java 20 is used, it will also find the class file, but it always gets some classformat error. We will in Java 20 add another source set (this time with same provider class name). The same finally in Java 21. <br><br>On all loading errors of our provider class it falls back to old impl. We have tests for all this including java 20 through CI. When java 20 comes out we add another source set,...<br><br>The SPI like code is in linked pull request, or here: <a href="https://github.com/apache/lucene/blob/branch_9x/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L329">https://github.com/apache/lucene/blob/branch_9x/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L329</a><br><br>Btw: It is now released, happy testing: <a href="https://lucene.apache.org/core/corenews.html#apache-lucenetm-940-available">https://lucene.apache.org/core/corenews.html#apache-lucenetm-940-available</a><br><br>Uwe<br><br><div class="gmail_quote">Am 30. September 2022 11:11:56 MESZ schrieb Alan Bateman <Alan.Bateman@oracle.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre dir="auto" class="k9mail">On 30/09/2022 08:40, Remi Forax wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi Uwe,<br>i wonder if you will not be in trouble when Java 20 will be out with your multi-releases jar,<br>because the VM 10 will try to run the bytecodes under the 19 folder and because it is compiled with --enable-preview --source 19, it will not work.<br><br>(Alan in CC, to check i'm not saying something stupid.)<br><br></blockquote>That's right. JDK 19 with --enable-preview will work. JDK 20 EA builds with --enable-preview will fail because the class file version will be 63.65535 rather than 64.65535. MR JARs are already complicated and it would greatly complicate it further if version sections were further divided to support classes compiled to make use of preview features. I'll bet Uwe/team understand that and they will need to add support for JDK 20 anyway. It looks like things are shaping up to have at least some shimmer in the j.l.foreign API in Java 20 so they probably have at least some work to do.<br><br>-Alan<br></pre></blockquote></div></body></html>