I ran across yet another set of posts on Slashdot where Swing is being bashed by people who obviously haven�t programmed in it for more than an afternoon. This got me thinking about many of the misconceptions of Swing and why they are made. First, here are a few issues I�ve seen MANY Swing programmers get hung up on:

• Swing components do not support multi-threading directly, so therefore many programmers believe all logic should be performed on the event thread
• Because it usually works to some degree, and it�s the easiest way to get the job done, many people believe they should always use the default models provided by Swing
• Everyone wants to subclass components to add functionality because they really don�t understand UI Delegates (or the limited role of a component in Swing).

There are many more of the concepts, but documenting them all would be an effort worthy of a book. I�ll stop with these three. I do believe (against apparent popular belief) that it�s programming mistakes like these that keep most Swing apps slow. I believe it�s only the large applications where memory usage comes into effect that the architecture itself causes significant performance problems.

I don�t want to spend any time proving these three concepts (if I get any requests to elaborate on any of them, I may in a future entry). For now, I want to talk about WHY Swing programmers don�t understand these concepts. It really comes down to prerequisites, documentation and the handicaps inherent of a component based system.

Basic Swing Books

Open most Swing books to the first chapter and you will find that the author expects only a basic understanding of the Java language. There is no assertion that the programmer understands threading of Java memory management. This is because the goal of most Swing books is to get the programmer up and running as soon as possible. The goal is NOT to create a competent Swing programmer, but to help the programmer to APPEAR competent as soon as possible.

Basic Swing books start by introducing each of the components (as a book on Visual Basic would do). It then shows how to use each component in the simplest of situations. Following this, the author will show how to change properties (usually through simple get and set methods) to change very simple physical of behavioral characteristics of the component. This will be repeated for each component for the remainder of the book. This is the basic format used to document any component based RAD tool. Swing, however is much more complex than the form designer�s of Visual Basic or PowerBuilder. That complexity deserves more attention.

Some of the better Swing books will also have a chapter at the end that shows the programmer how to change the look and feel. The chapter may also show a model explaining how the abstract factory pattern (employed by the Swing�s UI Delegates) works. Once again, this chapter will be more about making a programmer appear to be competent rather than teaching the philosophy of Swing. A programmer who knows how to change the look and feel, but not how (or more importantly when) to alter it, will look productive while only having to memorize three lines of code.

Advanced Swing Books

I have looked for suite a bit for a good advanced Swing book. Most of the books I�ve found so far seem to be nothing more than recipe books that explain parts of Swing that are readily available in the API (or in Sun�s documentation online). Some of the popular topics include:

• Building a Sortable or Filtered table
• Adding �advanced� editors to a table
• Creating a web browser from JEditorPane
• Drag and Drop
• Using JTree

What I would Like to See

I can understand wanting to get programmers up and running as soon as possible. Many programmers won�t buy a book unless they think it will allow them to see results almost immediately. What I don�t understand is why it isn�t communicated to the programmer that the simple solution isn't always the most correct.

Why isn�t there a follow up book that explains the other 30% of coding in Swing that all these intro books miss out on? The philosophy of Swing assumes that a competent Swing programmer understands threading, the limitations of the default models, how to implement new data models, and the responsibilities of Components and UI Delegates. There are also other philosophies such as the value of decoration over component inheritance and how listeners can cause memory leaks when misused. What I�m really looking for is a book like Joshua Bloch�s Effective Java that relates specifically to Swing programming� or better yet a book in the tradition of Thinking in Java, where the more advanced philosophies of Swing could be taught in conjunction with basic concepts.

Something that escaped the original complaints on Slashdot, is that Swing is complicated for a reason. When designing Swing, the authors had to choose between ease of use and flexibility. They choose the route of flexibility more often than not, which leave Swing much more complicated than GUI tools in other languages. If properly documented and understood by its programmers this can be a major advantage rather than the disappointment so many see it as today.

I've heard talk in private from quite a few Java professionals that .Net will one day replace Java. They point out that C# is a comparable language and most of the open source API�s are being ported to C# (and therefore to the rest of .Net). Microsoft obviously has more market pull than Sun (who rarely even gets respect from Java programmers). I can, in some ways, understand the fear.

Of course in reality, there isn�t anything to worry about. Java will not disappear. Porting open source projects to .Net will only help a handful of .Net programmers. C# will still fall behind Java in the area of cross platform support, vendor independence and effective use of the open source feedback loop.

Why doesn�t it help to port open source Java projects to .Net? Because Microsoft won�t directly support them, and lack of vendor support will make the projects useless. Very few companies will choose a development environment other than Visual Studio for their .Net development. Its very unlikely Visual Studio will have integrated Ant support. Microsoft will provide their own APIs for XML parsing, logging, preferences, etc. Most companies who choose .Net will ignore any open source project which improves on these APIs for the same reason they choose .Net in the first place: these companies want end to end tech support for their entire system; they want a single company to be responsible for the environment they use; these companies WANT a closed homogenous environment.

Why is Java safe? Because the companies that use Java today simply don�t have the same requirements as the Microsoft shops. Java and C# may be very similar languages, but they exist in completely different environments. Both environments have their pros and cons and both will flourish over the next 5-10 years.