uschindler commented on PR #13572: URL: https://github.com/apache/lucene/pull/13572#issuecomment-2350900783
> > Anyways: At moment we do not want to have native code in Lucene Core. > > +1, we don't put native code in Lucene's `core`. > > But @uschindler is there maybe a way forward not using core? I.e. add native code to `misc` or `sandbox` or so, to enable iterating on direct access to SIMD for early adopters (opt in)? > > Or is the `src/javaXX` approach core-only for some reason? In the current setup it is. One could generalize this, but this should be fine step by step in separate PRs. There are several problems to solve, also with regards to modularization and where the stub jars are: - compilation stubs (apijars) need to move to a common folder across Gradle projects (we don't have dich common module yet as core itself has no dependencies). - the bootstrapping of Panama and memory segment code is based on factories which are not yet pluggable. This may need SPI. So one could simply drop a separate JAR into class path/module path and then it enabled native code. - I would like to prevent duplicate and hairy initialization code, so one single place that loads the service providers and fies appropriate checks before. In general it's doable but I really doubt if this is healthy for this project's infrastructure. So I am still -1 to Gabe native code before we have refactored major parts. One condition is to have java 22 as minimum version, so we can at least introduce MemorySegment as top level citizen into our own APIs. I was arguing in the java community to have the foreign API stabilized and released with 21, but unfortunately it was done in 22. If we can get rid of the shit and simply tell our downstream users to accept java 22 as minimum version, and only the Panama vector stuff needs to be me jarred it would simplify a lot. 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: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
