From: ###@###.### (Ed Grossman)

We at NCSA are working on a large project to build a collaboration
environment using Java and AWT. We believe that one of the features that
was added to the prebeta release of AWT make it pretty much unusable for
that purpose.

Basically, all of the instance variables were declared private, and no
interface has been declared to allow subclasses to make changes to those
variables. This makes the AWT pretty much inextensible by anyone other
than the AWT developers, because subclasses have no more rights to their
internals than any unrelated class would have.

To be a little more specific, here are just a few extensions to AWT which
we would like to make, and which are impossible given the current
structure:

1) Create a Menu object which could change the order of its items, or add a
new item anywhere but the end.

2) Write a descendant of Container which could sort its children in place.
An example here would be a list of lines that had different columns, and
the whole list could be sorted on any column (the Eudora mail handler on
the Mac does this). Yes, you could fake this with a LayoutManager object,
but it would be very inefficient, and still would not provide a way to ask
for the nth line in the column. You would also not want to call invalidate
very time you changed a line, since you knew that all the lines were
moving, and one big invalidate call would be sufficient. It is, howver,
impossible to get direct access to the list of children.

3) Create an object which acts like a Checkbox (and type-checks like one)
but doesn't look like one.

4) As a descendant of Component, set my parent directly. There are a lot
of cases, when you know the topology of your parents and children, when it
is inefficient to go through the entire update chain every time you
move/show/hide/whatever an object. Especially if there are multiple
relocations.

I have had fairly extensive experience with a number of toolkits on X and
Macintosh platforms - I've even helped implement one, and none of these
examples have been difficult in any of them. If you want the AWT to be a
general purpose toolkit, as opposed to an applet-writing kit, these
concerns must be addressed.

We are also concerned by a somewhat more theoretical point. The AWT pushes
a lot of functionality onto the native toolkits - in particular coordinate
transformation and a lot of event handling. While this does ensure that
the native platform look and feel is respected, it makes extension more
difficult. Since most of the interesting code is not in Java, most
extensions to that code will also have to be in the native toolkit, and
thus written over for each platform. This reduces the gains Java's
multi-platform nature was supposed to ensure.

We hope you will carefully consider these concerns; we would be happy to
discuss them in more detail if you would find that helpful. We have
corresponded with Arthur van Hoff, but he doesn't seem to think there is a
problem.

Yours Truly,
Ed Grossman
Senior Research Programmer
Software Development Group
NCSA