Bootstrapping (Was: Non-ASCII characters and OpenJDK)

[Jonathan Gibbons]

On Aug 12, 2009, at 3:35 PM, Mark Wielaard wrote:

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


While it would not be wrong to specify boot.javac.source and  
boot.java.target
it should not be necessary if it is compiled and run with equivalent  
versions of
javac and java from the same ${boot.java.home}.


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