Re: SWING at OJE

[Rolf W. Rasmussen]

On Mon, Feb 05, 2001 at 01:56:03PM +0000, Nic Ferrier wrote:
> >>> "Rolf W. Rasmussen" <address@hidden> 05-Feb-01 9:29:40 AM >>>
> 
> >The worst problem with Swing is that it appears 
> >like a work in progress  where the line between 
> >public API and private implementation is muddled. 
> >Actually, I think Sun is digging themselves a hole, 
> >since I can't see how  Swing can be improved 
> >without breaking existing applications.
> 
> I agree. The seperation of layers is really bad and they keep making
> changes... I think Sun's real problem is the JNI which is not very
> useful for client side Java (thank goodness for GCJ and CNI).
> 
> Perhaps you guys would consider doing a Swing port for GCJ? Using low
> level stuff called from CNI when necessary?

GCJ was actually the target for the work I was doing on Swing. Here is a 
short version of the whole tale: I was implementing a little Xlib wrapper 
using GCJ and CNI. I found that to implement XImage manipulation 
efficiently I needed classes very much like the classes in java.awt.image. 
So I just as well created a clean-room implementation of most of 
java.awt.image. With a Xlib wrapper and java.awt.image in place, the 
natural extension was to create an java.awt implementation and a set of 
Xlib based AWT peers. The java.awt.image and Xlib peers are currently 
part of the GCJ CVS tree, and most of my java.awt work has been merged 
with into the current java.awt implementation. I've also committed the 
beginnings of a proper Java2D rendering pipeline. See <URL:http://
www.ii.uib.no/~rolfwr/jcnix/> for details.

Now, the Xlib peer implementation is built on basic Xlib functionality. 
This means that it doesn't have any components, just simple graphic 
primitives. So I would need to implement such components directly in 
Java instead of relying of native peers. This is exactly what Swing is. I 
implemented some basic Swing components (label, button) and created 
loop-back peers for AWT that utilized the Swing implementation to create 
heavyweight AWT components.

I have button and label for both AWT and Swing up and running, however, 
when I started to implement the more complex components, the deficiencies 
of both the Swing architecture and its documentation became painfully 
obvious.

The reason my Swing work hasn't been included in the GCJ tree is two-fold: 

    1.  I'm not certain that a complete Swing implementation will ever 
        become a practical goal.

    2.  There is some uncertainty about which strategy that should be used 
        to implement Swing in GCJ. It has been suggested that we should 
        base the implementation on GTK+. There are technical difficulties
        in doing so, and it would require rewriting or amending the
        current GTK+ implementation significantly. Search the GCJ mailing 
        archives for a few postings discussing this. One major hurdle has
        been removed since the last time it was discussed. Now the GDK 
        GC it virtual which allows an Java paint() invocation to pass a
        GDK GC that will loop back drawing operations to a Java Graphics
        object. 

I was initially a bit wary of dragging in GTK+ into the implementation, 
but I've changed my position a little since then. I realized that a 
complete reimplementation of things like Bidi and glyph shaping would be a 
massive waste of effort when there already exist libraries that do this.
Likewise, while implementing the document model of javax.swing.text I got 
the feeling that this is something that it would be a shame to implement 
just for Java Swing, when it clearly can be useful in a general library. 

Lately I've been compelled to go back and continue work on the Java2D 
rendering pipeline. I find it particularly exciting to see if the new X 
Rendering extension can be used to speed up rendering operations.

Also, as I mentioned earlier, I haven't had much time lately to devote to 
these things. Hopefully this will change...

-- 
Rolf W. Rasmussen