BootimageBuilder fails for jvm versions <1.6

Project:	JNode Core
Component:	Miscellaneous
Category:	bug report
Priority:	normal
Assigned:	Unassigned
Status:	active

Currently, the bootimage builder will fail if the JNode / Classpath tree includes classes in java.lang, java.util and a few other packages that do not exist in the JVM being use to run the builder. (And since
Classpath recently added at least one Java 1.6 class in java.util, we are currently limited to using a Java 1.6 JVM.)

This patch makes the bootimagebuilder work on Java 1.5.

The reason that the image builder is using the class loader is that it is using reflection to find out the values of static fields so that it can pre-instantiate classes in the boot image. This means that boot image builder ends up using static field values from the current JVM to populate the JNode JVM. This is flakey (to say the least!), but the flakiness is partly offset by the boot image loader avoiding copying static fields that are declared differently in the two JVMs.

This patch works by (in effect) treating any class that won't load in the context of the currently JVM as having no copyable static fields. As far as I can tell, it is producing viable boot images. However, I don't have much luck with the JNode GUI at the best of times, so someone else needs to check that part of the functionality.

It is worth noting that the code in my patch only "kicks in" when the normal class load fails with a Security exception. (You should be able to verify this by inspecting the code.)

Attachment	Size
issues_28	4.74 KB

JNode requires Java 6 for

Submitted by lsantha on Tue, 01/16/2007 - 07:28.

JNode requires Java 6 for building from source.
We have decided to go this way because more and more Java 6 features are being added to GNU Classpath and more similar problems will appear soon anyway. Java 6 is fast, JNode builds fine with it, it will be free soon and it's widely available. So we do not see a problem here and all we expect from someone willing to compile JNode is to use the best JVM for the job availab today.
Neverthless your patch and remarks are valuable for us and we are looking forward for more insightful feedback from you.
What do you suggest for fixing the 'flakiness' you pointed out in JNode's build process?

Regards, Levente

"Flakiness"

Submitted by Stephen Crawley on Tue, 01/16/2007 - 23:48.

I was meaning to elaborate on what I said.

I should start by saying that I may not fully understand what the bootimage builder is doing. I'm going from what I've learned by browsing the code, which is ... complex. It also appears that at least some of the code of the bootimage builder is used un conjunction with Isolates.

It appears to be using instantiations of environment classes (e.g. Java 6) as the source for static field values that it then writes to the boot image. The problem is that the actual classes written to the boot image are the JNode versions of the classes, not the Java 6 classes. The image builder tries to accomodate this by only copying static field values whose declarations are equivalent in both spaces.

There are problems with this approach. Static fields that are not equivalent won't be copied, and fields with equivalent types may not have appropriate values. I'm not sure what if anything the image builder is doing to address these problems. (Maybe annotations have been added to the JNode classes in problem cases?) Irrespectively, this approach is theoretically unsound, and fragile in practice ... as we observed when a change in Classpath broke the builds.

I can think of a couple of alternatives:

Have the bootimage builder dump uninitialized static fields to the the image, along with appropriate static <init> code. This would make the JNode VM bootstrap a bit slower, and might introduce some bootstrapping issues. But these can be worked through. (Been there, done that in Kissme.)
Have the bootimage builder use a special classloader so that it can always load the JNode versions of the classes. This might entail having the classloader massage the qualified names of the classes to avoid collisions and Security exceptions.