| [jpa-dev] Background on why SPEC APIs can compile with an earlier Java SE version than the Jakarta EE Platform SE minimum requirement |
Jakarta EE SPEC APIs need to be binary compatible with the
minimum (Jakarta EE Platform) Java SE version but that doesn't
require compiling with the minimum Java SE version as you can use
an earlier SE version and still have classes that are bytecode
compatible with the minimum Java SE version. We get this for free
with Java, as long as the related Java SE versions are compatible
in the sense that the minimum Java SE must not break anything that
the earlier SE version depends on.
Another interesting related fact is that for Jakarta EE 9.1, we
improved the TCK signature test tool [1] to support
-IgnoreJDKClass for making it possible to ignore certain JDK
classes that we used to validate SPEC APIs against. This means
that we still validate that the SPEC API classes depend on the
right JDK class name but we no longer validate the JDK class
fields/methods. This means that in general we can run TCK
signature testing against newer JDK versions and expect that to
mostly work due to [2]. This was done by including a list of JDK
classes to pass to -IgnoreJDKClass (the list cannot be changed by
users as its embedded in our TCKs). I'd like us to improve our
signature testing further to be more future (JDK) proof but this
is a good enough change for now. If future JDK versions include
new classes that might need to be excluded, we can always release
a TCK service release with an updated list of JDK to exclude.
Scott
[1] https://github.com/jtulach/netbeans-apitest
[2] https://github.com/jakartaee/platform-tck/issues/156