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.