natClass.cc, java::lang::Class::initializeClass() problems

Wed Dec 6 19:38:00 GMT 2006

Tom Tromey wrote:
>>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:
>> Marco> I'm trying to use AWT/Swing from a Sun 1.4.2_13 JRE. I can
> Marco> successfully compile a minimal AWT application with AWT/Swing
> Marco> from Sun instead of GNU classpath.
>> Note that this will require some work on your part.

I wouldn't expect that. It's nothing more than a couple (well, actually 
a lot) of class files and some libraries.
> Also the result is probably legally questionable.

True, but it's interesting anyway :-)
> Our AWT peer interfaces started out compatible with Sun's, but have
> diverged over time -- Sun un-documented these interfaces and so we
> made additions as we needed.

That doesn't matter. The public API is the same. So as long as the 
complete AWT/Swing API is provided on compilation, the classpath stuff 
will be ignored (not pulled into the binary). That works without problems...
Of course I'm always talking about static compilation. Shared might not 
be so easy...
> This isn't insurmountable, and it would be nice to be compatible
> here. But, you definitely want to know about this before starting :)

I don't really know what you mean, but I think there are no problems...
> Marco> 3. initIDs tries to load WComponentPeer (which is in the binary) but
> Marco> runs in a JV_STATE_ERROR in natClass.cc:719
>> How did you compile WComponentPeer? ...

I took all AWT/Swing classes out of the Sun rt.jar and then satisfied 
all depencies (by also taking all needed classes out of rt.jar).
That gives me a new jar that I compiled with "gcj -fjni -c foo.jar -o 
foo.o". It's not optimal but I'm just testing...
> Marco> Maybe a problem with JNI?
>> ... I'm wondering if you somehow forgot -fjni.

As I said, I was able to compile without any problems. If I omitted 
-fjni, compilation would have failed...
> Otherwise all I can suggest is some debugging.

Crap! I hoped for some GCJ specific points because of AOT compilation.
Calling initializeClass() through JNI while already in initializeClass() 
should be ok?
What about linux stacktraces? Is this a known problem?
thanks
Marco