Home | Business News | Browse by Publication | J | Java Developer's Journal

Trimming the fat from Swing. (Graphical API).

Article Excerpt
I'm sure we've all heard it before: Java on the clients is slow; Swing is slow. The reality is that Sun has made great progress in increasing the speed of Swing and Java on the client.

However, it's up to developers to demonstrate that Java has indeed improved to the point of usability and viability on the client.

To do this, the code needs to be very lean and clean. One of the original problems with GUI creation was the reliance upon Visual Development Tools to design and code the GUI. While these VDTs have come a long way in the last few years, I have found that many developers rely so heavily on the VDTs that they've gotten lazy when it comes to coding the actual functionality of the application.

The Problem

Methods are expensive in terms of execution time. The more method calls made, the slower the application will be. However, there needs to be a balance between speed of execution and good coding standards.

Swing makes a large number of method calls during its startup and execution. This is a price that has to be paid for its design model. What compounds the method calls that Swing requires is the number of method calls the average developer piles on top of Swing.

Multithreading Swing

The Swing API is considered to be single threaded and thread "unsafe." However, for a Swing GUI to be responsive, some actions must be threaded, such as database access.

In a normal GUI construction, if a call to a database is made, the GUI will just sit there waiting for the database access to return. Not only will...