<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
On 01/10/2022 15:26, Uwe Schindler wrote:<br>
<blockquote type="cite" cite="mid:53755fcd-6e0d-446c-2924-4ac390046145@apache.org">
<p>Hi again,</p>
<p>about Alan's comment:</p>
<p>> 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.</p>
<p>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):</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.<br>
</p>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
-Alan<br>
</body>
</html>