uschindler commented on PR #12033:
URL: https://github.com/apache/lucene/pull/12033#issuecomment-1369931777
> I also thought that the whole point of only enabling the memory segment
index with --enable-preview was to give a choice to downstream clients whether
to enable or not, and to test this in the real world (so as to provide
feedback).
Yes and no, basically the flag in the class files was mainly added to
prevent loading classes with preview *API* features in a JVM that has a
different major version (JEP 12: "A JVM implementation for Java SE $N must not
define a class file that depends on the preview features of a different Java SE
release, even if the JVM implementation would otherwise understand the class
file's version. Specifically, ClassLoader.defineClass must fail for the bytes
of the class file. **This prevents such class files from running years into the
future, long after the preview features that were enjoyed by the developer have
been removed or finalized in a different form.** In essence, Java SE $N+1 does
not claim backwards compatibility with the preview features of Java SE $N.").
I understand this as "there is a new preview API that may change, so class
files may not work anymore, but it is stable".
I think another important part is: "A preview API may add public members to
classes and interfaces in java.* and javax.*; add public classes and interfaces
to java.* and javax.*; add and export packages in the java.* and javax.*
namespaces; and add modules in the java.* namespace. A preview API may modify
the narrative specifications (though not the signatures) of pre-existing
methods, fields, classes, interfaces, packages, and modules. A preview API
typically resides in the java.base module, but may reside additionally or
exclusively in other java.* modules, including those introduced just for the
preview API."
Lucene is here the downstream consumer ("consumer of this new API"); the
downstream user of Lucene never get in contact with Panama APIs so,
Elasticsearch, Solr, or Lucene users can't give any feedback on the APIs.
Lucene already provides feedback about the API. Lucene 9.4 was our "test
balloon", now we think now that it works and performence is fine. We ca still
add a sysprop to disable, for sure.
Project Loom is different as it has big changes in the underlying JVM, not
only the API. Panama added its stuff already in Java 16 (memory scopes) and
mixed it into the inner implementation on ByteBuffers and other performance
critical classes.
> Java 19 has other preview features as well, namely Loom. In Java 19 there
were some startup regression when enabling Loom. To mitigate these regression,
Loom support is only enabled if the --enable-preview flag is detected
I think this is special, but also according to spec JEP 12: Because Loom has
two types of preview features: One inside the JVM and the other one
co-developed inside the class library. For the Panama this is not the case, the
code to access memory segments is always available because it also shares code
with many other features like ByteBuffers (that also use the memory scopes). So
ByteBuffers wont work if you would disable the scoped memory access.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
