Patch: FYI: re-enable xlib peers

[Scott Gilbertson]

> Scott>  1. I configured with --enable-java-awt=xlib, but the built
> Scott> executable is looking for the GTK toolkit
>
> I didn't try to reproduce this one, sorry.

The toolkit path used to be assumed correctly based on the config options,
but that's recently broken.  I figure it has to do with the Classpath
import.

> Scott> then says "Aborted".  Interpreted, it immediately aborts
> Scott> without apparently doing anything at all.
>
> I don't see this.  This kind of error is pretty serious ...

It doesn't happen with every program, and I can't really see what was going
on in order to produce a small test case.  It looks as though a throw isn't
working, but a trivial exception-throwing example works fine.  I just
fetched a new tree, which I'm building now, and I'll see if the abort still
happens with that build.

> I built the Classpath awt example.

That's pretty ambitious, since the xlib peers are lightweight-only apart
from Frame, Panel and Canvas.  I really should write a wiki page or
something, explaining how little the xlib peers do, but how useful they are
in spite of that, especially for statically built programs in embedded
systems.  For example, much of swing ought to work with xlib, because swing
basically only needs lightweights, but I haven't tried it.

The attached trivial awt program expects much less from the peers.  With my
July 18 gcc it works, but only if you define gnu.awt.xlib.XToolkit
explicitly.

> Exception in thread "main" java.lang.UnsupportedOperationException
>    at gnu.awt.xlib.XToolkit.getLocalGraphicsEnvironment
(XToolkit.java:364)

It doesn't seem to be anything new.  I get the same thing with that
particular source file, regardless of which gcc build I use.

The Classpath example creates a Dialog, which extends Window, which needs
toolkit.createWindow (), which isn't implemented in XToolkit.  I guess those
methods should be throwing UnsupportedOperationException instead of
returning null.

----- Original Message ----- 
From: "Tom Tromey" <tromey@redhat.com>
To: "Scott Gilbertson" <scottg@mantatest.com>
Cc: "Java Patch List" <java-patches@gcc.gnu.org>
Sent: Monday, August 22, 2005 12:56 PM
Subject: Re: Patch: FYI: re-enable xlib peers


> >>>>> "Scott" == Scott Gilbertson <scottg@mantatest.com> writes:
>
> Scott>  1. I configured with --enable-java-awt=xlib, but the built
> Scott> executable is looking for the GTK toolkit
>
> I didn't try to reproduce this one, sorry.
>
> Scott>  2. Building again with -Dawt.toolkit=gnu.awt.xlib.XToolkit,
> Scott> the resulting executable crashes (see backtrace below)
>
> Scott> The application (I tried both static and dynamic executables)
> Scott> runs for a second or so, and manages to put up some graphics,
> Scott> then says "Aborted".  Interpreted, it immediately aborts
> Scott> without apparently doing anything at all.
>
> I don't see this.  This kind of error is pretty serious ...
>
> I built the Classpath awt example.  When I run it with the xlib peers
> I see:
>
> Exception in thread "main" java.lang.UnsupportedOperationException
>    at gnu.awt.xlib.XToolkit.getLocalGraphicsEnvironment
(XToolkit.java:364)
>    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment
(GraphicsEnvironment.java:104)
>    at java.awt.Window.<init> (Window.java:231)
>    at java.awt.Dialog.<init> (Dialog.java:203)
>    at java.awt.Dialog.<init> (Dialog.java:180)
>    at java.awt.Dialog.<init> (Dialog.java:140)
>    at Demo$DialogWindow.<init> (D)
>    at Demo$MainWindow.<init> (D)
>    at Demo.main (D)
>
>
> I guess this is a new requirement on the toolkit that must be
> satisfied for things to work.
>
> Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Light.java
Type: application/octet-stream
Size: 1630 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20050822/8b62cc34/attachment.obj>