Hi committers,
this is a heads up. Please see the following PR:
https://github.com/apache/lucene/pull/12188
In short: It is very complicated for a committer to actually compile our
MR-JAR when a new Java version is not yet released on AdoptOpenJDK. This
makes testing early hard. In addition on every Java version (19, 20, 21)
the API of Panama-Foreign has slight differences, so we need to compile
against each version and ship the files in our MR-JAR lucene-core.jar.
The aproach in that PR is to get away with requiring the compiler, as we
just need to make sure that we compile against the correct classes and
method signatures. The trick is to have a "stripped JAR file" with only
the Project Panama class files in our Git repository, without any
bytecode. This allows the java compiler (JDK 11 or JDK 17) to compile
against those classes and produce a valid MR-JAR without having JDK 19,
20, 21 available on developers computer. The only persons who would need
thoseJava versions are those that want to regenerate our generated
files. The API signatures JAR files are saved in src/generated/jdk, one
for each Java version.
I am raising that issue on the mailing list to get some comments on the
issue: Is this OK to have *.apijar files in Git repo (each approx 20
KiB), are there any licensing problems? The bytecode is removed we only
have the API signatures (in binary form, we could add a dump of all
method descriptors for review next to the apijar files - I have some
code for that available). We already compile against those class files
so there's no "linking" problem, it is more the problem of if we can
ship with those API signatures.
Please respond in the Github issue.
Uwe
--
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
