Bootstrapping modules into Java

We plan to modularize the source of the Java compiler in Java SE 7, i.e. group its packages into modules. As with any large piece of software, modularization brings more precise dependencies, a clearer API, and easier reuse.

A module-aware compiler will be needed to compile the modularized SE 7 compiler source. The compiler in SE 6 is not module-aware. This is a problem because Sun has a policy that the Java compiler source for SE n must be compilable by the compiler in SE n-1. (And that the resulting SE n compiler can execute on SE n-1.)

We can solve the problem via a two-step process:

1) Bootstrap. We will use the SE 6 compiler to compile the SE 7 compiler source, hiding the package-info.java files which associate packages in the SE 7 compiler source with modules. The result of the SE 6 compiler run will be a "bootstrap" SE 7 compiler which is module-aware (knows how to compile modularized code) but is not itself modularized.

2) Modularize. We run the bootstrap SE 7 compiler on SE 6 to compile the SE 7 compiler source again. Since the bootstrap compiler is module-aware, the package-info.java files can be visible. The result of the SE 7 compiler run will be a "real" SE 7 compiler which is module-aware and is itself modularized.

Now we have a modularized SE 7 compiler, we need a module-aware JVM to run it on. The SE 7 JVM is written in C++ so can be made module-aware independently of these compiler shenanigans.

What about core libraries? A modularized compiler should ship with modularized libraries. Compiling a modularized library requires a module-aware compiler, which happily we have after step 1. So in step 2, we can run the bootstrap compiler on SE 6 to compile not only the modularized SE 7 compiler but also the modularized SE 7 library source.

Ultimately, we have a fully modularized SE 7 reference implementation, containing a module-aware JVM, a module-aware and modularized compiler, and a module-aware and modularized set of libraries.

Comments:

Now this is really good clear thinking.
Keep up the good work! :-D

Posted by david on June 25, 2008 at 06:30 PM PDT #

For the record, at least the last three javac releases use a bootstrap pass.
javac 1.5 had to compile enums without java.lang.Enum, 1.6 had to compile annotation processors without
javax.lang.model.\* and javac 1.4 was written with generics but had to
not compile them :)

Rémi

Posted by Rémi Forax on June 26, 2008 at 04:52 AM PDT #

Rémi,

The underlying point here is that the compiler should generally not use new language features in its own source code, because of the bootstrap issues. However, in this case, the language features for modules can be confined to the package-info.java and module-info.java files, and the compiler can be successfully compiled without these files, to produce a bootstrap compiler. Thus this is one of those fortunate cases where we can have our cake and eat it too, providing we remove the wrapping when we make the bootstrap compiler.

Jon

Posted by Jonathan Gibbons on June 26, 2008 at 11:27 AM PDT #

If there is a policy that "Java compiler source for SE n must be compilable by the compiler in SE n-1" it must have been introduced after I quit. NetBeans and other customers need javac to run on certain older Java SE releases. This implies that it must be possible to produce class files from the source code of javac that is compatible with the required older releases. It does not, however, imply that the the compiler must be compiled with a compiler from those older releases.

Posted by Peter Ahé on July 10, 2008 at 08:00 AM PDT #

Peter, the policy was a broad-brush statement to simplify the exposition. One can obviously expand the scope of "SE n must be compilable by the compiler in SE n-1" to include tricks like pre-compilation passes over the source of SE n, but the point of the entry was how a module system feature makes bootstrapping quite straightforward.

Posted by Alex Buckley on July 10, 2008 at 11:14 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

Alex Buckley is the Specification Lead for the Java language and JVM at Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds