Re: AWT peers (Was: [PATCH] More List fixes)

["S. Meslin-Weber" <twiun at adorphuye dot com>]

Hi everyone,

As a latecomer to this discussion, I'll reply to several parts at once:

On Mon, 15 Dec 2003 21:50:31 +0100, Mark Wielaard <mark@klomp.org> wrote:
> Hi,
>
> (Moved to java@gcc.gnu.org/classpath@gnu.org and added Chris and
> Stephane since they both work on AWT peers.)
>
> On Sun, 2003-12-14 at 00:20, Bryce McKinlay wrote:
> > On Dec 13, 2003, at 1:09 PM, Tom Tromey wrote:
> > > There's been some discussion about trying to make our peers conform to
> > > the JDK specification, even though it is undocumented.  It turns out
> > > there are other peer implementations around, it might be useful to let
> > > them work with our implementation.
> >
> > > What do you think about the compatibility idea?

My only reason for writing fbAWT and (re)writing QteAWT is specifically 
for use across JVMs, Sun's and Open Source ones; hence the compatibility 
idea is a must for me.

> > Are there any independently developed peer implementations (for Sun's
> > JRE) that work with anything newer than JDK1.1? I'm not aware of any.

Definately. The AWT Peer interfaces present in Sun's JDK have been pretty 
consistent from 1.1 to 1.4.2 (the one I currently use). I debug/develop my 
fbAWT peers under Sun's 1.4.2, but they work fine with Blackdown's 1.1.8 
linux port and the Jeode JVM. I've had limited success with J9 from IBM, 
namely because of their strange packaging strategy.

Kaffe, SableVM and JamVM testing is going well - currently held up by a 
Thread implementation bug.

See below for a list of independent open source AWT peer implementations. 
Note that searching for commercial ones is particularly difficult as 
they're not usually advertised directly.

> > Compatibility would be difficult given that there is no published spec,
> > also the interface is no doubt quite complex. The benefits would be
> > questionable - it would let us run our peers on Sun's JDK for debugging
> > purposes, but I don't think that advantage is worth the effort that
> > would be involved.

I disagree, although undocumented by Sun, Sun's Peer interface is 
reasonably well structured and intuitive to implement (if somewhat 
painstaking to understand without docs). And as Dalibor just found, there 
*is* published documentation for AWT peers, see my footnotes [1.1] and 
[1.2].

As GNU Classpath already implements big chunks according to this spec 
there wouldn't be a great deal more 'effort' involved. Any effort required 
is to keep GNU-isms segregated as much as possible outside of the java* 
packages (yes, I know that's not feasible for java.awt.Font yet).

And as for benefits, I think you're looking at this through a keyhole. 
Don't you want commercial development companies to be able to use open 
source JVMs for their peer implementations? Off the top of my head, 
Trolltech in Norway do QtAWT and they supply this to commercial JVM 
vendors (part of the Qtopia OEM bundle) and it's used in Jeode, J9, J2ME 
PersonalProfile. I'm reasonably confident that device OEMs would be 
interested in cutting companies like Esmertec (for Jeode) out of the cost 
equation for providing a JVM on their device.

Acunia, the guys that do the Wonka JVM also have a set of custom peers and 
they use Sun's AWT Peer interfaces - wouldn't we like to be able to use 
their implementations (native framebuffer and framebuffer in X)?

> > In the long run, however, it may well be worth stabilizing and
> > documenting _our_ peer interface so that others can develop peers
> > independently of libgcj.

Agreed - whatever those interfaces look like, documentation and stability 
is key.

> The only free AWT peer implementation I know of is PJA (Pure Java AWT).
> But I haven't tried it with any of the free VMs and our awt
> implementation. http://www.eteks.com/pja/en/

I listed a few others as well on the kaffe mailing list[2.1], but here's 
the list again:

- PJA, Pure Java AWT [2.2]
- Charva, Java Windowing Toolkit for Text Terminals[2.3]
- RAWT, Remote AWT from IBM [2.4][2.5]
- TUIAWT, Text UI AWT [2.5][2.6]
- fbAWT, pure java framebuffer AWT peers [2.7]
- QtAWT, Peers for the Qt widget toolkit [2.8] (unfortunately not publicly 
available _yet_)
- QteAWT, not complete or publicly released yet and tested under Wonka 
[2.9] - waiting for Classpath integration into Kaffe.
- EWT, Embedded Windowing Toolkit [2.10]
- Goodness, Extended AWT Toolkit [2.11]
- and a few other AWT replacements that could be quickly reimplemented as 
peers (jcurses, VNCj, etc).

> Both Chris and Stephane are working on AWT peers so they might have an
> opinion.

Thanks for CC-ing me in this thread Mark, I'm now subscribed to java@gcc 
as well.

Stephane

P.S. Thanks Dalibor for the first two links below and for giving me the 
idea of using such footnotes.

Some footnotes:
[1.1] Chapter 23 of the Java AWT Reference, 
http://www.oreilly.com/catalog/javawt/book/
[1.2] UML of the whole AWT, including peers, 
http://www.soberit.hut.fi/tik-76.278/group6/awtpat.html
[2.1] http://www.kaffe.org/pipermail/kaffe/2003-December/044644.html
[2.2] PJA: http://www.eteks.com/pja/en/
[2.3] Charva: http://www.pitman.co.za/projects/charva/
[2.4] RAWT from IBM, 
http://www.alphaworks.ibm.com/aw.nsf/toolpreview/3EAF80466042CC4B8825671B0067D1E3
[2.5] RAWT and TUIAWT in action 
http://www.ii.uib.no/~rolfwr/seminar/bridge/notes/bridge53.html
[2.6] TUIAWT: http://www.bmsi.com/tuipeer/
[2.7] fbAWT: 
http://adorphuye.com/zaurus/java/faq.jsp?section=Java+Extensions&subsection=fbAWT
[2.8] QtAWT: http://www.trolltech.com
[2.9] QteAWT: http://adorphuye.com/~twiun/
[2.10] EWT: Mentioned in http://alumni.cse.ucsc.edu/~wholt/thesis.pdf, 
believed to exist in his Java Nanokernel
[2.11] Goodness: 
http://www.mooseyard.com/Jens/Software/RichChocolatyGoodness/RichChocolatyGoodness.html