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

[Marco Trudel <mtrudel at gmx dot ch>]

Tom Tromey wrote:
> Marco> That doesn't matter. The public API is the same. So as long as the
> Marco> complete AWT/Swing API is provided on compilation, the classpath stuff
> Marco> will be ignored (not pulled into the binary). That works without
> Marco> problems...
>
> Sorry, I thought you were merely using the peers, not replacing
> awt+swing entirely.  My mistake.
>
> Marco> Crap! I hoped for some GCJ specific points because of AOT compilation.
>
> It could be, but we don't have enough info to know, I'm afraid.

I continued working on using AWT/Swing from a Sun JRE 1.4.2_13. I was 
able to solve a couple of problems by setting system properties that 
weren't set and thus cause NullPointerExceptions. What makes this so 
difficult is, that stacktraces (at least in statically linked 
applications) seem pretty unreliable on Windows and Linux. For example 
the initial problem from this thread: "java.lang.NoClassDefFoundError: 
sun.awt.windows.WComponentPeer" is actually a NullPointerException and a 
missing library. In both cases the same stacktrace is shown and this 
stacktrace is wrong (or incomplete).

The problem I'm currently working on is this Exception:
Exception in thread "AWT-Windows" java.lang.NullPointerException
   <<No stacktrace available>>
Exception in thread "main" java.lang.OutOfMemoryError: null pData
   at 
java.lang.VMThrowable.fillInStackTrace(/home/Marco/.eclipse_workspace/GCC-source/libjava/java/lang/natVMThrowable.cc:33)
   at 
java.lang.Throwable.<init>(/home/Marco/.eclipse_workspace/GCC-source/libjava/classpath/java/lang/Throwable.java:159)
   at 
java.lang.Error.<init>(/home/Marco/.eclipse_workspace/GCC-source/libjava/classpath/java/lang/Error.java:80)
   at 
java.lang.VirtualMachineError.<init>(/home/Marco/.eclipse_workspace/GCC-source/libjava/classpath/java/lang/VirtualMachineError.java:70)
   at 
sun.awt.windows.WComponentPeer.<init>(D:/programming/nativeJ/resources/tests/inWork/awt-1.4/needed/needed.jar:0)
   at 
sun.awt.windows.WCanvasPeer.<init>(D:/programming/nativeJ/resources/tests/inWork/awt-1.4/needed/needed.jar:0)
   at 
sun.awt.windows.WPanelPeer.<init>(D:/programming/nativeJ/resources/tests/inWork/awt-1.4/needed/needed.jar:0)
   at 
sun.awt.windows.WWindowPeer.<init>(D:/programming/nativeJ/resources/tests/inWork/awt-1.4/needed/needed.jar:0)
   at 
sun.awt.windows.WFramePeer.<init>(D:/programming/nativeJ/resources/tests/inWork/awt-1.4/needed/needed.jar:0)

I assume that the OutOfMemoryError is created while trying to create the 
stacktrace for the NullPointerException, but I'm not entirely sure.

I tracked the NullPointer to a PeekMessageW() call in awt.dll. The 
PeekMessageW() call gets the same arguments when running on a Sun JRE 
and when used by a GCJ compiled Java application, but only the GCJ one 
creates the NPE.
From http://msdn2.microsoft.com/en-gb/library/ms644943.aspx:
The PeekMessage function dispatches incoming sent messages, checks the 
thread message queue for a posted message, and retrieves the message (if 
any exist).
I assume that there are problems with the thread. But I don't fully 
understand how this is now handled with mingw and Visual Studio. The 
awt.dll is compiled/linked with Visual Studio, so I would assume it 
directly uses user32.dll in both cases what would mean IMHO that this 
PeekMessageW() call should work (since it's exactly the same).
But what about the threads? Somewhere there has to be a meeting of the 
mingw world and the visual studio world, but I don't know where or if 
this is the source of the problem...

Any ideas from the professionals?


thanks
Marco