Support ML-KEM with Java 21 and 17 (from 10/2026 patch day) and Java 11 and 8 (H2 2027)

[beth-soptim]

Starting with October patch day Java 21 and 17 will support ML-KEM:

https://www.java.com/de/jre-jdk-cryptoroadmap.html

OpenJDK is also following this roadmap:

https://bugs.openjdk.org/browse/JDK-8298390

21 -> https://bugs.openjdk.org/browse/JDK-8389458
17 -> https://bugs.openjdk.org/browse/JDK-8389616

The backports to 11 and 8 are planned for H2 2027.

Please note that Java 17 also includes KEM api since version 17.0.13 (Java SE 17 Maintenance Release 1 -> https://jcp.org/aboutJava/communityprocess/maintenance/jsr392/jsr392-mr1-changes.html)

[mwiede]

Thanks for this info. Once the JDKs are published, the ML-KEM classes can be compiled with 17+21 and the multi-release jar can be reorganized.

[beth-soptim]

I think this needs some special treatment because Java 25 compiler seems to refuse compilation because 25 does not include metadata that KEM API was also added in SE 17 MR 1.

Maven toolchains might be required (= using a JDK 17 to compile Java 17 classes).

[norrisjeremy]

Hi @beth-soptim,

I suspect that the reason #1120 fails to compile is because we need to wait for the next Java 25 release in October, which hopefully will be updated to include the SE 17 MR 1 changes when compiling for release=17.

Thanks,
Jeremy

[beth-soptim]

Hi,

I think it will be required to use 17 to compile 17 source code with KEM API because 21, 25, ... contain the "since 21" info in ct.sym file.

The backport of the KEM API has already happenened in 2024 in version 17.0.13 -> https://bugs.openjdk.org/browse/JDK-8336893

It seems that only in 17 the ct.sym file contains the "correct" information.

https://github.com/openjdk/jdk17u-dev/blame/master/src/java.base/share/classes/javax/crypto/KEM.java (since 21)
vs.
https://github.com/openjdk/jdk21u-dev/blame/master/src/java.base/share/classes/javax/crypto/KEM.java (since 17, with "This class is defined in Java SE 17 Maintenance Release 1")

[norrisjeremy]

Hi @beth-soptim,

If the base compiler from Java 25 turns out to be incapable of compiling these changes, then I am inclined to not include them.
Convoluting the build process by requiring multiple distinct JDKs to handle this would make maintaining JSch a headache.

Thanks,
Jeremy

[beth-soptim]

Hi,

I can see how toolchains would overcomplicate the build process.

I think I might have found a workaround for this: f28176c

[norrisjeremy]

Hi @beth-soptim,

I left a comment in your PR.
The use of the ignore.symbol.file compiler option concerns me, as everything I can immediately find about it indicates that it is an undocumented internal flag.
If that is true, it means that the OpenJDK team could change or remove it at any point.

Thanks,
Jeremy