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