Re: [javaCompiler-users] Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit

[Stephen L. <lon...@gm...>]

Hi Marco,

Thanks for the really quick reply, I appreciate all the good advice.

> First of all, AWT and Swing is not ready for real applications. There
> are two possibilities for it right now:
> - swingWT; it maps AWT and Swing to SWT. A lot is still missing here
> until it's complete... But it's open source, you can enhance it to
> support all your needed stuff.

This is a possibility.  When I extracted the classes from my jar and
ran javaCompiler, I received some error messages at the compilation
stage relating to missing methods.  One example was
BufferedImage.getRGB.  It looks like the swingWT code doesn't yet
support all the things my graphics code uses.  If I were to add the
necessary code to swingWT, would it be easy to then use this with
javaCompiler again?  Would it just be a case of updating
swingwt-all.jar and swingwt-win.jar.o and swingwt-lin.jar.o?

> - AWT/Swing from gnu classpath (used by gcj). On linux it works only for
> shared applications, not for static. On windows it doesn't work at all.
>
> swingWT is currently the better choice... If you create a managed AWT or
> Swing project, this will be used. If you create a unmanaged project, the
> classpath AWT/Swing classes will be used (but because javaCompiler only
> creates static applications, this will fail anyway).

So basically, using AWT/Swing from gnu classpath won't work at all
with javaCompiler at the moment, on Windows or Linux?

> Now, after that intro, lets take a look at your problem:
>
> > I tried it out an a game I've written in Java, that uses the
> > java.awt.Graphics2D stuff fairly heavily, along with BufferedImage
> > objects, but no AWT widgets or anything.
>
> Ok, then you might use external libraries to bypass the current
> AWT/Swing problems...

This was something I am seriously thinking of doing.  I need to
re-factor my code so that the screen rendering, resource loading and
user input are abstracted away from any specific system.  This should
be pretty easy actually.  If I then switched to SWT directly, that
would hopefully give me a better chance of getting something compiled
natively.

>
> > After building a windows .exe from my jar file (thats classes, not
> > source), I get the following error when running it:
> >
> > Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit:
> > gnu.java.awt.peer.gtk.GtkToolkit
> >    at java.awt.Toolkit.getDefaultToolkit(game-win.exe)
> >    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment
> > (game-win.exe)
> >    at java.awt.Window.<init>(game-win.exe)
> >    at java.awt.Frame.<init>(game-win.exe)
> >    at java.awt.Frame.<init>(game-win.exe)
> >    at com.longsteve.GameFrame.<init>(game-win.exe )
> >    at com.longsteve.Game(game-win.exe)
> > Caused by: java.lang.ClassNotFoundException:
> > gnu.java.awt.peer.gtk.GtkToolkit not found in
> > gnu.gcj.runtime.SystemClassLoader{urls=[file:.\],
> > parent=gnu.gcj.runtime.ExtensionClassLoader{urls= [], parent=null}}
> >    at java.lang.Class.forName(game-win.exe)
> >    at java.awt.Toolkit.getDefaultToolkit(game-win.exe)
> >    ...6 more
>
> That's the error message when using AWT/Swing from gnu classpath. Even
> on a simple hello world programm that uses java.awt.Dimension, the whole
> AWT toolkit will be loaded (what fails with this message)...
>
> > I used "Managed AWT or Swing project" to start with.
>
> Shure? That would mean that my adaptions of the classes fail on some
> points and gnu classpath is used instead of swingWT...
> Or did you use a jar? Classes in a jar are not preprocessed for swingWT...

I did use a jar as input, yes.

> If you used a jar, unpack your classes and try with them. With luck,
> swingWT covers all your requirements.

After unpacking my jar, the compilation step now gives errors.  It
looks like there are parts of the JDK 1.5  AWT/Swing API that are not
yet implemented.  The first errors I get are that
swingwt.awt.image.ComponentColorModel is missing, then
swingwt.awt.image.BufferedImage is missing various methods, including
a constructor I use, and the getRGB method.  There will probably be
more if I got the compilation past these.

> If you used classes directly, please use the source and try again. If it
> works, I'd be interested in the class that wasn't adapted for swingWT.
> Maybe you can find it...

I think your adaptations are working correctly, but that swingWT does
not yet implement enough of the API that my code needs.

This is all very promising.  I think I will re-factor my code so that
it can use SWT directly first, then re-attempt to get a natively
compiled version running with javaCompiler.

Thanks very much for your time,

       Steve