This is the mail archive of the
java-patches@sources.redhat.com
mailing list for the Java project.
Re: Patch: Xlib AWT and Java 2D
- To: "Rolf W. Rasmussen" <rolfwr at ii dot uib dot no>
- Subject: Re: Patch: Xlib AWT and Java 2D
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Mon, 23 Oct 2000 15:36:50 +1300
- CC: java-patches at sourceware dot cygnus dot com
- References: <20001022023931.A710@amy>
"Rolf W. Rasmussen" wrote:
> I intend check this in. It adds an Xlib based AWT toolkit and a few
> Java 2D rendering classes. Classes from the gnu.awt.xlib and
> gnu.gcj.xlib are now excluded from libgcj.zip, the library is linked
> with X11 and the makefile use the correct values from the X11 autoconf
> test.
Rolf,
Cool stuff - thanks! A few notes and thoughts:
I'd like to make LightweightDispatcher pkgprivate and move it into java.awt
(actually, might as well put it into Container.java - Sun have it there
according to my stack trace). This way it can be made more efficient by
referring to component bounds and such directly rather than by calling
getX()/getY()/etc. I think it is generally safe and desirable to bypass the
get methods within the awt implementation itself. LightweightPeer should
probably go in there too for the sake of continuity.
It is interesting how Container has a dispatcher field according to the
serialization spec. I don't know how we can achieve serialization
compatibility when this class isn't documented, but this does imply that
dispatcher maintains some state data. I wonder what?
Going back to the discussion on package names, eventually we may want to split
the classes into two distinct hierarchies:
1. those classes that are referred directly from java/awt, and do not have any
native code dependencies. These are the classes that are required to build the
pure-java java.awt classes, even if there is no peer implementation.
2. those classes that are dynamically loaded (eg peers), and may have native
code and/or dependencies on native toolkits. These classes are optional.
This is an important distinction because the second group can only be reused
by other runtimes and platforms if they support CNI somehow or rewrite the
natives using JNI, but the first group is pure-java and totally reusable as-is
by other implementations.
There's no immediate need to make this change however, but for now I would
like to see the number of different packages we're currently spread across to
reduce a little. What do you think about moving the files left in gnu/gcj/awt
into gnu/awt and/or gnu/awt/j2d?
regards
[ bryce ]