Name: krT82822 Date: 03/08/2000


A large number of Java developers see a strong need for the AWT to continue to
grow and expand. We feel that AWT development has suffered due to the
overwhelming effort required to get Swing up on its feet. And now that Swing is
mature, it's time to revisit the AWT and incorporate support for more enhanced
gui components.

The intent of this letter is not to encourage the end of Swing, nor to argue
which is "better". Rather, it is to reaffirm the fact that the AWT plays an
indispensable role in Java development, and to lobby for real, increased effort
towards a more complete AWT.

Both Swing and the AWT have their place. There are times when each one is most
appropriate. That choice is left to the developer. Some obvious reasons for
developers to choose the AWT over Swing include:

* Real native Peers achieve true platform independence and an authentic Look And Feel.
* Speed.
* The AWT is years of development effort ahead of Swing, and it shows; both to
the developer and the user.
* Reduced learning curve for new developers.
* There are cases where heavyweight components are necessary; i.e. in order to
make use of native display technologies, such as QuickTime or OpenGL. Even
Java3D requires the use of heavyweight components. And mixing lightweight and
heavyweight components causes problems.
* Swing makes many tacit assumptions about a platform's LAF. For example, menus
in windows and MDI.
* Platform-specific LAF's can't completely mimic a platform's true LAF. Most
successful applications usually use the platform's native controls. Not doing so
can compromise an application's acceptance by users.

Furthermore, an extended AWT would be a huge boost to Real Native Application
  Development in Java.

Both Swing and the AWT can continue to develop in parallel quite happily.
Developers to whom Swing is a boon will continue to reap its rewards. There are
also many advantages that Swing has over the AWT. However, they do not outweigh
the disadvantages that come with Swing's use in places where it is not
appropriate. This situation leaves developers with the needlessly time/energy/
money consuming task of writing or acquiring, and supporting 3rd party widgets in
a cross-platform environment. This hole can be filled with an extended AWT.

In conclusion, we feel that extending the AWT's capabilities is a natural and
meaningful endeavor. We also feel that in many cases, the AWT is a much stronger
windowing toolkit than Swing is, as the authenticity of native Peers is
elementary for a good user experience. We hope to see a richer set of components
in the AWT's future.

In anticipation of a real plan of action on this front, the development community
awaits Sun's candid comment and reply.


P.S.

We acknowledge the fact that this project would most likely place burden not only
on Sun but on it's licensees as well. It is our hope that the mere potential of
this does not adversely influence Sun in deciding the next step to take on an
issue which affects the development and end user community at large. Hopefully,
increased participation can actually bring this goal closer to realization.


 - This message composed by <name removed, per privacy policy> with
input from the community.
7 March, 2000.
(Review ID: 102160)
======================================================================

The following comments come from bug 4419288 (closed as a duplicate):

- Dialogs should be able to have menu bars.
- FileDialogs should have a "select folder" mode. (see bug 4037524)
- FileDialogs should use FilenameFilters, and not simply ignore them. (see bug 4293697)
- TextAreas should offer both line wrap and word wrap.
- TextComponents should allow using multiple fonts and styles within a single component.
- AWT should offer true floating windows.
- It should be possible to set a default button for a window or dialog.

michael.martak@Eng 2001-02-27