Modules which use nb-javac can't change their source/target/release level
Modules which use nb-javac (requires.nb.javac=true in project.properties) can't change their source level at the moment since they prepend the bootclasspath and this is only allowed on java 8.
https://www.oracle.com/java/technologies/javase/9-relnotes.html
The boot class path has been mostly removed in this release. The java -Xbootclasspath and -Xbootclasspath/p options have been removed. The javac -bootclaspath option can only be used when compiling to JDK 8 or older. The system property sun.boot.class.path has been removed. Deployments that rely on overriding platform classes for testing purposes with -Xbootclasspath/p will need to changed to use the --patch-module option that is documented in JEP 261. The -Xbootclasspath/a option is unchanged.
consequences:
- since
targetisn't (and can't) be set either once boot cp is modified, no API checks are active (!) - code is linked against the build JDK (!) (this already has caused problems in past if I remember correctly)
- the release has to be built with the min required JDK and CI has to catch API version bugs since safeties are off
- code is stuck to Java 8 syntax
some thoughts:
-
--patch-module(JEP 261) might work if nb-javac was a JPMS module? - making a JPMS module out of nb-javac is likely easy and would have the benefit to be able to drop the jackpot transformation step, since projects like https://github.com/kohlschutter/jdk.compiler.standalone indicate that upstream javac code is kept on JDK 11 language level, it can be built with no transformation
- some modules might be buildable without nb-javac if release is set to 17 or later, which could be a way to reduce usage of
requires.nb.javac=truein NB 22+ - i don't think there is a immediate need to fix this but at some point this is going to become more pressing.
- it might be worth to explore if a new flag like
test.requires.nb.javac=truewould make sense, since many modules do only set the flag right now to be able to run the tests.