The infrastructure to bootstrap J2SE is extremely fragile. Specifically,
the bootstrap jar files (gjc.jar and collect.jar) have to be hand-tuned
each time they are generated. This cannot be autmated.
We'd like to simplify the bootstrap process considerably, making it less
dependent on the skilled creation of these jar files. Specifically, we'd
like to be able to produce a version of javac that can run on 1.4.x and
target 1.5.x. Once that is done, the bootstrap jar files should be able
to be produced automatically.
The main difficulty is that javac uses features of the 1.5 platform.
Each of these features will require a workaround. These workarounds will
be handled automatically by javac when generating the code, using a secret
javac "bootstrap" flag, so that javac can compile itself to produce this
bootstrap compiler.
Here are the issues:
(1) generics. Since these are not visible to the VM, no
workaround needed.
(2) static import. Ditto.
(3) autoboxing. The workaround is to use the existing
constructors instead of the static factories.
(4) foreach arrays. No workaround needed.
(5) foreach Iterable. Instead of using the interface
Iterable, we use java.util.Collection.
(6) unicode surragates and support libraries.
When the "bootstrap" flag is set, these will not be
supported. Javac will simply avoid executing
calls to the support libraries in bootstrap mode.
(7) enum. These require the class java.lang.Enum, which
is not present in 1.4. The bootstrap flag will cause
javac to generate the needed support code locally -
that is, within each enum type. But since we violate
the spec in this mode (not extending java.lang.Enum),
we will only support this translation when bootstrapping
javac (that is, in the package com.sun.tools).
This work has also been requested independently by BEA, Borland, and the
Netbeans teams, who have offered engineering support for this work.
the bootstrap jar files (gjc.jar and collect.jar) have to be hand-tuned
each time they are generated. This cannot be autmated.
We'd like to simplify the bootstrap process considerably, making it less
dependent on the skilled creation of these jar files. Specifically, we'd
like to be able to produce a version of javac that can run on 1.4.x and
target 1.5.x. Once that is done, the bootstrap jar files should be able
to be produced automatically.
The main difficulty is that javac uses features of the 1.5 platform.
Each of these features will require a workaround. These workarounds will
be handled automatically by javac when generating the code, using a secret
javac "bootstrap" flag, so that javac can compile itself to produce this
bootstrap compiler.
Here are the issues:
(1) generics. Since these are not visible to the VM, no
workaround needed.
(2) static import. Ditto.
(3) autoboxing. The workaround is to use the existing
constructors instead of the static factories.
(4) foreach arrays. No workaround needed.
(5) foreach Iterable. Instead of using the interface
Iterable, we use java.util.Collection.
(6) unicode surragates and support libraries.
When the "bootstrap" flag is set, these will not be
supported. Javac will simply avoid executing
calls to the support libraries in bootstrap mode.
(7) enum. These require the class java.lang.Enum, which
is not present in 1.4. The bootstrap flag will cause
javac to generate the needed support code locally -
that is, within each enum type. But since we violate
the spec in this mode (not extending java.lang.Enum),
we will only support this translation when bootstrapping
javac (that is, in the package com.sun.tools).
This work has also been requested independently by BEA, Borland, and the
Netbeans teams, who have offered engineering support for this work.
- relates to
-
JDK-4985504 bootstrap VM used to run GenerateBreakIteratorData lacks surrogate support
- Resolved