You are talking about an idealistic situation that is divorced from reality.
When using the -target option, I need to set the bootclasspath at the same time -- at least in theory. But in the real world, I have never seen this option set in the build script of any project. If I open an issue in a project for this problem, the most likely thing is that the project maintainer will ask me what is the significance of doing this. All the project maintainers I met are happy to let the project compile on more JDKs. Even if this may cause some problems at some time, they always regard the incompatibility of some JDK versions as a problem, rather than requiring that compatible JDK must be used for building. So far, there are no exceptions. The same is true for the --add-exports option. Of course, I know that the internal classes may be modified at any time, but is it meaningful to require that a certain version of JDK must be used for construction? This is not only meaningless, but also covers up problems that should have been found during compilation. As for multi-release jar...Don't you know its problems in the real world? Build tools, IDEs, static analysis tools... We solved a problem with multi-release jars, and then we had a lot of problems with multi-release jars. Let's stop discussing the conflict between the ideal situation and the workarounds in the real world, OK? Let's go back to the issue -- Java 9 has added some new API methods. The javadoc of these methods does not have @ since tags. Is this an oversight? On Sat, Dec 31, 2022 at 4:38 PM Alan Bateman <alan.bate...@oracle.com> wrote: > On 30/12/2022 19:11, Glavo wrote: > > I agree that it is a good choice to use -release or set bootclasspath. > > However, this is not always realistic. > > > > Using -release means that we will encounter many JPMS problems. > > For example, using --add-exports for system modules is not allowed > > when using -release. > > This combination of options doesn't make sense. If you are going off > piste and compiling against JDK internal classes then you'll need to > have that JDK present on your file system. A release number maps to the > language and APIs in that release, it can't be expected to know about > JDK internal classes that happen to be a JDK build as they can vary and > shimmer by vendor or update. Maybe if you could expand a bit on what you > are doing so it can help you avoid the configuration issue in your build. > > > > > > In addition, sometimes we may want to deliberately bypass the > > restriction of -release: > > We may use some new APIs of higher Java versions in our code. > > As long as we check the Java version at runtime and ensure that the > > code path is not executed > > when running on a lower version of Java, this is also reasonable. > > > This reads like you want to compile to --release 8 but have static > references in version 52 class files to APIs that were added in Java 9+, > is that right? This may be a setup for a world of hurt and maybe you > should explore Multi-Release JAR files for this. > > -Alan >
