Bootstrapping (Was: Non-ASCII characters and OpenJDK)

Andrew John Hughes gnu_andrew at
Mon Aug 17 19:16:02 UTC 2009

2009/8/17 Mark Wielaard <mark at>:
> Hi Andrew,
> On Mon, 2009-08-17 at 17:20 +0100, Andrew John Hughes wrote:
>> 2009/8/12 Mark Wielaard <mark at>:
>> 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

After some experimentation:

* OpenJDK7 (from the IcedTea forest) builds fine on its own (i.e.
without IcedTea) using IcedTea6.  So we haven't picked the bug Martin
and I had on OpenJDK6.
* has always passed -1.5 to ecj as it defaults to 1.4.
Leaving this in causes langtools to fail in build-bootstrap-javac:

  [javac] Compliance level '1.5' is incompatible with source level
'1.6'. A compliance level '1.6' or better is required

* changing this to 1.6 causes a later failure in build.classes.javac

 [javac] Compliance level '1.6' is incompatible with source level
'1.7'. A compliance level '1.7' or better is required

* getting rid of it altogether allows langtools to build and breaks
corba which isn't setting source/target:

-J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m -encoding ascii -d
/mnt/builder/icedtea7/openjdk-ecj/build/linux-amd64/corba/btclasses \
	    -sourcepath ../../tools/src

This only works on IcedTea because it defaults to a higher
source/target version.

* using 1.7 in works for me, but clearly not for mjw.

So I think we need to remove the option and specify it explicitly when
needed.  Which means some more OpenJDK fixes are required.
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

More information about the discuss mailing list