On Tue, 22 Nov 2022 20:50:04 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> In JDK-8297041, the javacserver was moved out of the JDK itself, and lifted > out as a separate buildtool. Due to this, internal classes in jdk.compiler > were no longer available. Therefore, the closest way to calling javac as > before were to use `com.sun.tools.javac.Main.compile()`. This method is > however deprecated for removal, and relying on that was only needed as a > temporary measure during the transition. > > After the major refactoring of the javacserver tool in JDK-8297444, it will > be easy to replace the Main.compile API with the official ToolProvider API > instead. Well, I assume so. If this does not work properly, the problem will most likely be already in JDK-8297444; this patch is just choosing a different path to end up in the same class, as far as I can understand. The thing that makes (or should make) us chose the interim javac is the `$(INTERIM_LANGTOOLS_ARGS)` which is passed to java when launching the server. (This is since these flags are passed in the config file to the client as `javacmd`). I'll add some test output code to the interim compiler to verify that it is actually executed, both in JDK-8297444 and in this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11299
