Hi,
in theory we can't (see above), because there are some problems with
java compiler as the main sources are compiled with "-release 24", but
the incubator is not part of official API and this gets problematic (as
unstable). To ensure that our main classes get all checks by the
compiler and are compatible with the release version, we have to exclude
the incubator classes. In addition, if we want to compile that with our
current module infrastructure, we would need to add
"jdk.incubator.vector" module part of our module-descriptor. But as it
is an optional feature (needs explicit enablement), we can't do this. As
alternative the whole setup could also be a separate JAR file and
separate gradle module in lucene "lucene-core-vector24.jar" with an SPI,
but for convenience we merge the classes into the main jar, so user does
not need a separate maven dependency to add and get incubator
vectorization. So we have a separate sourceset instead of a separate
Gradle module.
Because of all this the sourceset *is* needed, also with Java 24. In
future, when the incubator API gets new features or propagated to
"preview" we need additional sourceset anyways and have to replicate all
classes and therefor I don't want to even try to get rid of the current
setup. The current state is easier to maintain and also have the bonus
of better separation (regarding making incubator classes accidentally
part of our public API). All java24 classes are excluded form javadocs
and are not exported by module definition. Ass all of them containing
code are package private and you can only get an instance of the
VectorizationProvider from a stack-trace inspecting mechanism based on
"SharedSecrets" concept, we have a good separation.
Just to question: What was you original intention to merge the classes
to main sourceset? To me IDEs are perfectly fine with the current state.
Just some additional info: From what I figured out, cherry-picking to
stable branch is possible, although the sourceset and directories have
different names, becazuse git is intelligent enough to recognize this
like a file rename.
Uwe
Am 08.07.2025 um 22:00 schrieb Michael Sokolov:
I think I see - in theory we could merge into the "regular" source,
aside from the extra hiding, but we might have to recreate this as
soon as we start messing around with JDK25. I guess as long as we
track JDK-specific features (incubation, preview, etc), then we need
this.
On Tue, Jul 8, 2025 at 11:17 AM Uwe Schindler <u...@thetaphi.de> wrote:
Hi,
This is because the compilation/processing is different. The files are compiled with a
Java 24 API extract (apijar file) of the Incubator modules and are NOT compiled against
the current JDK. In addition it allows us to make sure no classes from there appear in
public APIs or can be referenced from there. This is done because compilation with
"-release" does not work with a later JDK like 25 (as it is not part of
backwards compatibility) and the APIs may suddenly change in later Java versions.
Therefore the compilation is done using a stub:
https://github.com/apache/lucene/tree/main/lucene/core/src/generated/jdk
In addition when Panama Vector enters Preview mode (should happen hopefully
soon after Java 25) we need a separate sourceset anyways.
Uwe
Am 08.07.2025 um 16:58 schrieb Michael Sokolov:
I'm curious why we have lucene/core/src/java24 directory/module on main branch
instead of moving these classes to lucene/core/src/java, now that JDK24 is
mandatory.
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
