RFR: 8297041: Remove the last remnants of sjavac

[Magnus Ihse Bursie]

On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The sjavac ("smart javac") was an ambitious project. It should parallelize java compilation, create a background daemon process that kept the JVM "hot" with the JITted javac code, define a public api so only noticeable changes in a class caused further dependency compilations, etc etc.
> 
> Some of this never came to fruition. Other were implemented differently, as the `depend` plugin. The only thing we're currently using (and have been for the last few years) is the "server" functionality, that is, the ability to keep a single JVM process alive, and reuse the JITted code.
> 
> This code does not belong in the jdk.compiler module. It is a buildtool, pure and simple. Let's move it to it's proper place.

Some more detailed explanations of the changes I've made in this patch.

* I have stripped down the original sjavac code to retain only the "javac server" part, and associated machinery. In some cases it can probably be possible to cut out even more baggage, but I had to draw the line somewhere.
* The remaining sjavac code has moved to `make/langtools/tools`, together with the other langtools buildtools.
* All sjavac jtreg tests in langtools has been removed.
* A few non-sjavac-related tests (for AppCDS) references sjavac. My interpretation is that these classes were just picked arbitrarily as a good representation, so I have modified these tests to pick other, arbitrary classes. (I'd like to have some input from AppCDS folks that I did this correctly)
* I have verified that it is still possible to build with, and without, the javac server, and that there has been no build performance regressions.
* The original implementation used a class internal to the `jdk.compiler` module to actually kick off the javac compilation. This was no longer an option when moving out of the module, but fortunately there is actually an exported class that does the same, `com.sun.tools.javac.Main`. This is however deprecated, and I realize it is not ideal to introduce a dependency to a deprecated class (but see below).

On a longer term, the current javac server tool is under scrutiny, and it will probably be rewritten into a more general "portal" to run other langtools binaries such as javadoc. It will also be transformed into using the ToolProvider API, which will solve the problem of calling the deprecated method. @sormuras is working on this.

-------------

PR: https://git.openjdk.org/jdk/pull/11185