Bootstrapping (Was: Non-ASCII characters and OpenJDK)

[Andrew John Hughes]

2009/8/12 Mark Wielaard <mark at klomp.org>:
> [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.
>

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.

> 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.

 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 javac.in script did have to be changed to pass -1.7 instead of 1.5
to build with this latest version (this applies to ecj only).  After
that, it worked AFAIR.  You could try reverting this and see if it
helps.  It's also worth checking what is being used by Ant and what is
being used by bootstrap/ecj.
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.

> 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
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8