JEP 199: Smart Java Compilation, Phase Two
Summary
Improve the sjavac
tool so that it can be used by default in the JDK build, and generalize it so that it can be used to build large projects other than the JDK.
Goals
Due to various issues relating to stability and portability, sjavac
is not used by default in the JDK build scripts. The first goal of this JEP is to resolve these issues. This involves making sure the tool produces reliable results on all software/hardware configurations at all times.
The overarching goal is to improve the quality of sjavac
to the point where it can serve as a general purpose javac
wrapper able to compile large arbitrary Java projects.
A follow-on project will explore how sjavac
is to be exposed in the JDK tool chain, if at all; this might be a separate supported standalone tool, an unsupported standalone tool, integration with javac
, or something else.
Non-Goals
It is not a goal of this JEP to introduce new features that are not in place today, not required by our own build scripts, and do not contribute towards a general purpose javac
wrapper. The intent is not to do a rewrite of the wrapper. Current functionality that works well will be kept as-is.
The incorporation of sjavac
into the product, if desired, will be the subject of a separate JEP.
Motivation
The current implementation has proved to be useful and does indeed improve build speed and allow for incremental builds. The quality of the code and stability of the tool as a whole, however, is not satisfactory and it is certainly not ready for public release.
Description
This work builds upon the previously-delivered implementation described in JEP 139. The work described in this JEP will be performed gradually by writing, testing, and committing incremental patches to the existing implementation.
Initially the work focus on resolving issues related to building the JDK. This includes addressing:
- JDK-8014510 Fix
sjavac
on all platforms in JPRT - JDK-8019239 Properly clean up
sjavac
heuristics
Other issues that will be dealt with include:
- Refactor the protocol, possibly by leveraging RMI
- Make the option names and syntax more consistent with those of
javac
- Replace
System.{out,err}
logging with something more suitable - Increase parallelism by sharing more resources in
javac
, where possible
Issues to be addressed further down the road include, but are not limited to:
- Internationalization
- Support for Jigsaw
Certain adaptations of javac
will be required. Most notably, javac
will have to be refactored to allow for multiple concurrent compilations to share common data structures to enable better speed up and higher CPU utilization on multicore machines.
Testing
Beyond the usual mandatory unit tests, sjavac
will be thoroughly tested on all platforms since parts of the tool involve platform-specific aspects such as file paths and the spawning of background processes.
Furthermore, sjavac
will be stress-tested with concurrency in mind, since the server-client architecture is inherently parallel.
Dependences
The work proposed by this JEP builds upon the result of JEP 139: Enhance javac
to Improve Build Speed.