Bootstrapping (Was: Non-ASCII characters and OpenJDK)

[Mark Wielaard]

Hi Andrew,

On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
> 2009/8/12 Mark Wielaard <mark at klomp.org>:
> It's been possible to bootstrap OpenJDK with the GNU toolchain since
> June 2007 (with a few workarounds) and that setup has certainly been
> capable of compiling 1.6 source files.  Given, AFAIK, the only changes
> between 1.5 and 1.6 were verifier changes, I don't see why it would be
> a problem.  Without being able to do this, there wouldn't be an
> IcedTea and it seems unlikely OpenJDK would be in current GNU/Linux
> distributions.

Precisely. Which brings us to...

> > Although IcedTea can indeed also try to bootstrap things with 1.5
> > capable tools (most of this is now disabled in IcedTea7 I see)
> 
> What has been disabled?  I still run every new IcedTea7 build with
> gcj.  Nothing has changed AFAIK.

IcedTea (specifically patches/ecj/icedtea.patch) used to set explicit
-source/target 1.5 options. Mostly at the same points that now also have
such settings in openjdk7. So those have been removed to not conflict.
But they are now explicitly 1.6, no longer 1.5.

This isn't a problem with newer/patches gcj/gij, since those do accept
class major version 51 (even though it don't use the stack maps), but
older gcj/gij doesn't accept such major class versions. (As you point
out above, there is no real advantage using 1.6 over 1.5 in the VM. As
long as the class library supports the needed 1.6 classes - as gnu
classpath does.)

> The problem is there is not one but three 'JDKs' in the mix here.
> It's even more complicated if you consider each of them can be a mix
> of different VMs and compilers.  Things would be easier to debug if
> Ant wasn't being used.

Yes, ant makes things just that much more interesting... :}

I have slowly gone through the build to try to have the "tool
classes" (that need to be run during the build) and the "final rt
classes" (that don't need to be run during the build) have explicitly
compiled with the -source/target specifically set. Not fully there yet.

The biggest problem is the jdk build. There are a couple of tools that
are run during the build but that depend on com.sun.* classes that are
(also) compiled as part of the runtime rt classes.

This currently only work by accident. There are two slightly different
ways this can happen:
a) because you are using a bootstrap vm that already has those com.sun.*
classes on the bootclasspath (the wrong old version is used then, not
the just compiled one, but the one in the bootstrap vm core class
libraries).
b) because you use a bootstrap vm (like newer gcj/gij) that accepts a
mix of major class versions (1.6/50 for the tool classes and 1.7/51 for
the rt classes) when running the java build generation tools (this will
work until one of the accidentally included new rt classes will actually
start using invokedynamic, it already fails with gcj/gij that don't
accept such newer 1.7/41 classes - such as the gcj/gij on Debian
stable.).

Cheers,

Mark