Of
all the libraries in Java, the AWT has seen the most dramatic changes from Java
1.0
to Java 1.2.
The Java 1.0 AWT was roundly criticized as being one of the worst designs seen,
and while it would allow you to create portable programs, the resulting GUI was
“equally mediocre on all platforms.” It was also limiting, awkward,
and unpleasant to use compared with native application development tools on a
particular platform.
When
Java 1.1
introduced the new event model and Java Beans, the stage was set – now it
was possible to create GUI components that could be easily dragged and dropped
inside visual application builder tools. In addition, the design of the event
model and Beans clearly shows strong consideration for ease of programming and
maintainable code (something that was not evident in the 1.0 AWT). But it
wasn’t until the GUI components – the JFC/Swing classes –
appeared that the job was finished. With the Swing components, cross-platform
GUI programming can be a civilized experience.
Actually,
the only thing that’s missing is the application builder tool, and this
is where the real revolution lies. Microsoft’s
Visual Basic and Visual C++ require their application builder tools, as does Borland’s
Delphi and C++ Builder. If you want the application builder tool to get better,
you have to cross your fingers and hope the vendor will give you what you want.
But Java is an open environment, and so not only does it allow for competing
application builder environments, it encourages them. And for these tools to be
taken seriously, they must support Java Beans. This means a leveled playing
field: if a better application builder tool comes along, you’re not tied
to the one you’ve been using – you can pick up and move to the new
one and increase your productivity. This kind of competitive environment for
GUI application builder tools has not been seen before, and the resulting
competition can generate only positive results for the productivity of the
programmer.