On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie <[email protected]> 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
