Great news: Lucene 9.4 (optionally) uses mapped MemorySegments when JDK 19 is detected

[Alan Bateman]

On 01/10/2022 15:26, Uwe Schindler wrote:
>
> Hi again,
>
> about Alan's comment:
>
> > 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 think when the Preview specification was written, maybe some section 
> like this would have been nice to have. The only change that would 
> have been needed is in the classloading logic (searching for class 
> file in ClassLoader):
>
>     When the JVM/classloader searches for a class, and it figures out
>     that the version in a feature-version specific MR-JAR part is a
>     preview class (based on minor version 65535), it should ignore it
>     unless the JVM's feature version is exactly the one of the MR-JAR
>     section. Because it is treated as "does not exist", it would go
>     down to lower feature versions in the versions folder until a
>     valid one is found.
>
> This would have been an backwards compatible change, as it would only 
> affect classes marked as preview. This would have made it simple for 
> use, because we could have used a real MR-JAR in Lucene. Now we have a 
> provider class (see previous mail) and some try/catch logic with 
> UnsupportedClassVersionError as signal to detect preview and/or wrong 
> version.
>

There's nothing to force all class files in a MR JAR versioned section 
to have the same class file version. A versioned section may contain 
resources that aren't class files. It's important that a MR JAR provide 
a consistent view at run-time and that means that APIs such as 
ClassLoader.getResource need to be consistent with class loading. It 
gets further complicated once there URLs to resources in a MR JAR come 
into existence.  So on the surface, having a class loader attempt to 
load a class from versions/19 and fallback to older versioned sections 
on CFE might look simple, it fraught with issues. I've no doubt that it 
would be feasible to extend the MR JAR format to support version entries 
for class files compiled with preview features but it would add more 
complications and risks the curse of dimensionality.

As a general point, preview features were envisaged for developers using 
a preview feature directly. In the discussion here we can think of 
Lucene as a library that is published with class files using preview 
features. You don't want to force all users to run with JDK 19 and 
preview features enabled so you've got code to handle all that. It's 
great that you got this working, it's just not clear to me that the 
platform should go out of its way to make this easier.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221002/d0cb217b/attachment.htm>