Bootstrapping (Was: Non-ASCII characters and OpenJDK)

[Mark Wielaard]

[sorry if this becomes a duplicate, I sent the original from an
unsubscribed address to the list, hopefully resending from the address
actually subscribed to the list now.]

Hi Jon,

On Mon, 2009-08-10 at 07:48 -0700, Jonathan Gibbons wrote: 
> The boot JDK must support Java 6 or better.  From the message in the  
> previous line about annotation processing, it would seem you're not using a  
> version of javac capable of compiling -source 6 files.

Although IcedTea can indeed also try to bootstrap things with 1.5
capable tools (most of this is now disabled in IcedTea7 I see) I don't
think that was the issue in this case. It might be related though.

IcedTea goes out of its way to try to make openjdk "bootstrappable"
through the existing GNU java toolchains. So maybe some of the effort of
tuning the -target and -source for the new 1.7 source/target have been
biting each other. This might be more visible with IcedTea because the
existing GNU java toolchain isn't monolithic like the openjdk one, so
the core libraries, runtime vm and/or the compiler might have different
source/target defaults and coverage.

The CompilePropertiesTask that the original error was about had a class
major version of 51, which indicates it was generated through -target
1.7 (or at least some compiler defaulting to 1.7). But since that class
is used in the bootstrap cycle I think it should explicitly target 1.6.

So I think this part in langtools/make/build.xml needs an explicit
source="${boot.javac.source}" and target="${boot.javac.target}":

        <javac fork="true"
               executable="${boot.java.home}/bin/javac"
               srcdir="${make.tools.dir}/CompileProperties"
               destdir="${build.toolclasses.dir}/"
               classpath="${ant.home}/lib/ant.jar"/>

The same thing happens later in the build with some other classes that
are compiled and then run using the bootstrap tools.

The corba stripproperties classes. The BOOT_JAVAC_CMD in
corba/make/common/BuildToolJar.gmk doesn't define a source or target,
they should probably be defined in as BOOT_CLASS_VERSION in
corba/make/common/shared/Defs-java.gmk as alternative to CLASS_VERSION
since these classes will be run during the build on the bootstrap
runtime vm.

Similarly for the hotspot gamma classes. They are compiled with
COMPILE.JAVAC defined in hotspot/make/linux/makefiles/rules.make which
could if using ALT_BOOTDIR be the bootstrap compiler and runtime. So
should probably also include an explicit target/source setting.
Similarly for the jvmtiGen classes that are run using the bootstrap
runtime vm.

Especially the jdk build is a bit tricky since some things like the
generatebreakiteratordata and javazic tools that are run during the
build to generate classes and/or new source/property files combine
classes that will go into the new rt.jar, and so have been compiled with
-target 1.7, with tools build classes (like sun.text or
sun.util.calendar classes) which have been compiled with -target 1.6,
and that should be run by the bootstrap jdk (which is only capable of
understanding 1.6 classes). This can be solved by making a copy of those
classes and putting them in to tool package so the whole tool is 1.6
runnable, but this is slightly ugly because that means you build stuff
twice (once for -target 1.6 to run the tool and once for -target 1.7 to
put into rt.jar).

I'll try to go through a whole build (currently stuck on the bootstrap
rmic not liking to generate Stub classes for some of the new-target 1.7
classes) and suggest some real patches. That is after I made sure it
isn't caused by some of the IcedTea "cleanup" patches that already try
to do the same thing. And if any of the above sounds terribly wrong,
please do yell and shout, so I take another step back.

Thanks,

Mark