uschindler commented on PR #15843: URL: https://github.com/apache/lucene/pull/15843#issuecomment-4098123603
> @uschindler > > > the warning isse is the same if you don't enable vectorization preview. > > Sorry, but it really isn't because in the vectorization case I can silence the logger, in this case here my JVM will print the following: > > ``` > 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 (file:/usr/local/tomcat/webapps/ROOT/WEB-INF/lib/lucene-core-10.4.0.jar) > 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 > ``` That's the same for Vectorization, the only difference is that it only happens To get rid of the warning pass the correct command line parameter. This PR does not fix the issue. The easiest is to disallow or allow native access (see test config on other PR). It is not Lucene's problem how you configure your JVM. > > Actually: Your enum could also be accidentally loaded. The enum constants are also initialized on class loading so the same problems occur. So theres no reason to actually make a holder. > > Yeah, you're right, my mistake. But IMO that means we should still change the current implementation, just not to an enum singleton holder but instead a double locking pattern (or something else that does not have the class loading issue). Why. There is no issue during class loading. If you are afraid you need to do this for every clinit anywhere in Lucene. It is impossible that the code fails after the other PR is merged. If an exception is thrown, your JVM is broken anyways. Lucene is very strict on exceptions, e.g. we never ever catch Throwable and swallow or don't report. The patterns seen here is at many places, e.g. Panama vector init, Lucene 10 Mmap, Expressions module,... - we have many static initializers that may fail if your JVM is broken. The exception handling is always strict. We never ever intend to catch or swallow Throwable. It's always rethrowed if unknown, also in static initializers. Sorry, Uwe -- 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]
