Update maven-indexer to 7.1.3 and lucene to 9.11.0

[mbien]

• update maven-indexer from 7.1.2 to 7.1.3
• update lucene from 9.10.0 to 9.11.0
  • enabled --enable-native-access=ALL-UNNAMED
  • lucene's vector API binding can be manually activated by adding --add-modules=jdk.incubator.vector to the launch config

log:

WARNING: A restricted method in java.lang.foreign.Linker has been called
WARNING: java.lang.foreign.Linker::downcallHandle has been called by org.apache.lucene.store.PosixNativeAccess in an unnamed module
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled
WARNING [org.apache.lucene.internal.vectorization.VectorizationProvider]: Java vector incubator module is not readable. For optimal vector performance, pass '--add-modules jdk.incubator.vector' to enable Vector API.

something we could potentially enable

output on JDK 21+ with --enable-native-access=ALL-UNNAMED and --add-modules=jdk.incubator.vector set:

INFO [org.apache.lucene.store.MemorySegmentIndexInputProvider]: Using MemorySegmentIndexInput and native madvise support with Java 21 or later; to disable start with -Dorg.apache.lucene.store.MMapDirectory.enableMemorySegments=false
INFO [org.apache.lucene.internal.vectorization.PanamaVectorizationProvider]: Java vector incubator API enabled; uses preferredBitSize=256; FMA enabled

The JDK 17 launcher seems to ignore --enable-native-access without a message. (NB is setting -XX:+IgnoreUnrecognizedVMOptions already anyway):

WARNING [org.apache.lucene.internal.vectorization.VectorizationProvider]: Java vector incubator module was enabled by command line flags, but your Java version is too old: 17

[mbien]

have to investigate

WARNING [org.netbeans.modules.maven.indexer.NexusRepositoryIndexerImpl]: cleanup failed

although this might be one of my drives failing.

edit: this was indeed one of my SSDs which had errors on the file system

[matthiasblaesing]

The change to the module list, adding an incubation module, looks like a bad idea to me. It will break once jdk.vector graduates as the incubation module can then not be resolved and the launcher will not start.

[mbien]

The change to the module list, adding an incubation module, looks like a bad idea to me. It will break once jdk.vector graduates as the incubation module can then not be resolved and the launcher will not start.

if the module isn't there it would just print a warning. (i falsely assumed that it behaves like --add-opens)

Lets say vector api goes final in JDK 25, all we have to do is to switch from the preview module to the final module for NB 2x.

We can't really give forward compatibility promises for NB - it is on a best effort basis. So lets say JDK 25 changes the vector api while making it final and lucene is unlucky and the binding breaks, it is outside our control anyway (no matter what flags are set).

[mbien]

you are right. --add-modules is not ignored by the JVM if the module isn't there, only --add-opens is.

so we probably shouldn't do that

[matthiasblaesing]

if the module isn't there (e.g on JDK 17 or at some point in future), it would just print a warning.

Where does this come from? This:

matthias@enterprise:~$ java --add-modules=X test.java
Error occurred during initialization of boot layer
java.lang.module.FindException: Module X not found
matthias@enterprise:~$ 

looks like the VM will fail hard.

[mbien]

the remaining question is should we set --enable-native-access=ALL-UNNAMED or not

[matthiasblaesing]

the remaining question is should we set --enable-native-access=ALL-UNNAMED or not

From my POV it would make sense to set it. It will most probably be necessary in the future anyway. If I understand the recent discussions on the openjdk mailinglists correctly, JNI loading will become restricted the same way as the foreign API (panama) and modules using JNI will need to be cleared the same way. To my understanding this will also affect JNA, which used JNI to load its FFI interface.

The option is also guarded by the -XX:+IgnoreUnrecognizedVMOptions option (at least I deduce that from this):

matthias@enterprise:~$ ~/bin/jdk-11/bin/java -XX:+IgnoreUnrecognizedVMOptions  --enable-native-access=ALL-UNNAMED test.java
Geht
matthias@enterprise:~$ ~/bin/jdk-11/bin/java  --enable-native-access=ALL-UNNAMED test.java
Unrecognized option: --enable-native-access=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
matthias@enterprise:~$

[mbien]

I just noticed that lucene turns off its vector binding on JDK 23 which is a bit unfortunate (they are also using gradle so they likely can't build on it yet). Maybe there will be another lucene release before NB 23 is out so we can update it in time.

WARNING [org.apache.lucene.internal.vectorization.VectorizationProvider]: You are running with Java 23 or later. To make full use of the Vector API, please update Apache Lucene.

PR updated, it sets only the native access flag now

[matthiasblaesing]

Only eyeballed, but change looks sane.