Another reflection bug; compatibility results

[Stuart Ballard]

Godmar Back wrote:
> 
>  Have you tried calling 1.2's Class.forName(,false,) and then
> using getField().getValue() on a final static field?
> Does doing this invoke <clinit>?

I need to be able to run on 1.1...

> If not, we should be able to fix Kaffe accordingly; I bet 10:1
> it will call <clinit>.
> 
> But, actually, I don't really understand what that should be
> good for anyway.  The only reason that accessing a final/static
> field is not an active use is so the compiler can inline these
> constants.

This is a fairly specific situation that is probably extremely rare. My
program attempts to print out a description of the public API of a class
in a machine-readable format that can then be compared to other such
descriptions. Compile-time constants are part of the public API, other
fields' values (even public static final ones) are not. Reflection
doesn't let me distinguish between the two cases.

The issue of calling <clinit> came up when Edouard suggested using a
Classloader to make it possible to load libraries of other
implementations (eg load the JDK1.0 classes from Kaffe so that I could
print the API of 1.0, even though it doesn't have reflection). The
problem with doing this would be that the act of asking for a public
static final field's value would cause <clinit> to load, which would
cause nasty native code conflicts.

Even fixing Kaffe so that <clinit> doesn't get called on a primitive
constant access wouldn't help without a way to detect *in advance*
whether it was a primitive constant. So for my purposes at least it
wouldn't help.

Stuart.

PS rebuilding Kaffe now to test your fix for the other problems...

> 
> >
> > I may have to resort to one of these bytecode-interpretation libraries
> > eventually :(
> >
> 
> I very much recommend it and I recommend JavaClass in particular.
> Extremely easy to use - all types are named exactly as in the VM spec.
> You can pretty much code without looking at the API.
> 
>         - Godmar