Should Swing have changed in Java 1.5?

[Ben Ritchie]

I've never really liked Swing very much. The learning curve is very steep, and while it's very flexibile it also gives the beginner plenty rope to hang themselves with. Every developer I know has heard of a horror story, few like it and i've seen some truly awful, unmaintainable designs. In fact, Swing has something of a reputation for turning otherwise successful projects into unmitigated disasters.

As far as I can tell from Sun's website, the only change to Swing is a new theme, "Ocean". Has Sun missed a chance to address what many people think is a major weakness of Java?

[Alan Moore]

I was expecting some major improvements to Swing in Tiger. For instance, several well-known (and long-standing) deficiencies in the Action architecture were finally going to be addressed, and JTabbedPane was supposed to get a complete makeover. But they backed off, and concentrated their efforts on the Ocean theme (which is pretty nice, I have to admit) and the Synth (skinnable) Look & Feel. In other words, they chucked substance in favor of style. I'm not ready to give up on Swing yet, but something major had better happen in the next release.

[Jeff Langr]

My disappointment is that it doesn't appear as if any of the new features (generics, enum, etc.) were applied to the Swing libraries. It is a separate group at Sun that builds Swing, and apparently they don't coordinate much.

-j-

[Wade Chandler]

I happen to love Swing. Contrast it to other GUI API's and you'll find it has much more there than most. It is better than the Win32 API's, Better than standard X, GTK/+, and definitely better than wxWindows. I also think it is better than SWT. I think maybe QT gives it a run for it's money, but I still think Swing is the best.

I think people tend to only see the standard ugly look and feel and get lost on that, but the controls, extendability, and beans can come in very handy. I think most tools for gui building don't come up with their own bean utilities to register for their tools to manipulate the swing beans and instead expect Sun to dole them all out, so the gui designer tools end up not manipulating the GUI as best they could and we do more by hand, but at least we can do more by hand if needed.

Contrast that to other gui programming by hand. Any examples of other GUI apis being easier by hand than the swing api's? I haven't seen any to date.

Wade

[Thomas Paul]

My main complaint against Swing is that it is way too complicated to do even simple things. Unless you are a regular user of Swing, it is very difficult to throw together a quick, simple application. .NET is much easier for GUI development.

[Wade Chandler]

.Net by hand coding or .Net inside visual studio? Swing by hand or in an IDE. My point is that the Swing API is actually good, and the main problem is the designers. Sun has some generic default editors for the swing objects (bean editors) which are not as best as one can be. The IDE developers just never seem to make any real good ones to differentiate themselves from each other with the Swing APIs and Java.

Wade

[Warren Dew]

Wade Chandler:

I think people tend to only see the standard ugly look and feel and get lost on that

I don't think so. I've used Swing only with Apple's Aqua look and feel, and it's beautiful. The problems with Swing for me are in how it's implemented and documented, and I think those are the major complaints for most people who use it.

Contrast that to other gui programming by hand. Any examples of other GUI apis being easier by hand than the swing api's? I haven't seen any to date.

I have, and a very telling one. I recently started porting an application from Macintosh OS 7 to Swing. I figured, OS 7 is ten years old, it should be much easier to reimplement the interface using Swing, right?

Wrong. While Swing provides nearly as many useful widgets, it had two major disadvantages:

(1) The Swing layout managers are very poorly documented in terms of how they actually size components. Some pay attention to minimum, preferred, and maximum component dimensions, others ignore them. Worse, some pay attention to them, but only some of the time. Worst of all, this behavior is almost 100% undocumented. You end up wasting many hours tweaking the interface layout, where in the Mac OS 7 system, you could specify sizes and dimensions exactly, and things would show up the way you expected the first time. I estimate that programming the UI for this port actually took about twice as long as for the original product, despite the fact that there should have been time savings from the UI design already being done.

(2) The Swing documentation on behavior is incorrect. My very first post on JavaRanch concerned a situation where a call was documented as blocking but was not. I talked to perhaps half a dozen Swing-knowledgeable people on that issue, and they all agreed the call should block. I figured I was doing something wrong, but when someone very helpfully looked at my code and tried it out on a different platforms (I was on OS X, he on Windows), it behaved the same way. As a result, I'm worried that even after porting, the application will be much less usable, because the user will have to watch the application as it is being used. The original application could be used from the keyboard without looking at it much. I'm guessing that this change will cause a 3x productivity loss for the user.

To compensate for these two major disadvantages, Swing has zero advantages relative to the OS 7 interface. Wait - it has one, Apple doesn't ship OS 7 machines any more, which is why I have to do this. I just assumed that the lack of forward progress was because Sun had laid off all its Swing staff. If they actually still have a Swing group, though, they need to fire everyone in it and hire some competent programmers to replace them.

[somkiat puisungnoen]

AWT
Release 1.5 features many AWT enhancements and bug fixes, including some that have often been requested by our customers. Most notably, the new MouseInfo class makes it possible to determine the mouse location on the desktop. New Window methods make it possible to specify the default location for a newly created window (or frame), appropriate to the platform. Another Window enhancement makes it possible to ensure that a window (or frame) is always on top. (This feature does not work for some window managers on Solaris/Linux.) In the area of data transfer, the new DropTargetDragEvent API allows the drop target to access transfer data during the drag operation.

Swing
With the 1.4.2 release we provided two new look and feels for Swing: XP and GTK. Rather than taking a break, in 1.5 we're providing two more look and feels: Synth, a skinnable look and feel, and Ocean, a new theme for Metal. Beyond look and feels, we've added printing support to JTable, which makes it trivial to get a beautiful printed copy of a JTable. Lastly, after seven years, we've made jFrame.add equivalent to jFrame.getContentPane().add().

[Ko Ko Naing]

Originally posted by Wade Chandler:
I happen to love Swing. Contrast it to other GUI API's and you'll find it has much more there than most. It is better than the Win32 API's, Better than standard X, GTK/+, and definitely better than wxWindows. I also think it is better than SWT. I think maybe QT gives it a run for it's money, but I still think Swing is the best.

I do love Swing too... I've ever developed Windows application using Win32 API, when I was in the university, studying in the class "System Programming"... but I found it very difficult to catch the programming concept than Swing's...

I tried Swing and at least for me, I don't find it as difficult as Win32 API programming...

But I'm now studying about the SWT, which is the next step for me to learn GUI in Java...

[Ko Ko Naing]

Originally posted by Thomas Paul:
My main complaint against Swing is that it is way too complicated to do even simple things. Unless you are a regular user of Swing, it is very difficult to throw together a quick, simple application. .NET is much easier for GUI development.

Hi Mr.Thomas,
Maybe because I am a regular user of Swing, I don't find it difficult to develop a quick, simple application... I usually rely on the GUI DnD of JBuilder to accomplish simple Swing applications...

I'm not sure about the ease of use in .Net... But I use to develop Win32 Applcation using Visual C++ 6.0.... It's extremely difficult for me to get a small program done within one night of coding, while I can finish it within a few hours using Swing...

But now I'm falling in love with SWT.... :roll:

[somkiat puisungnoen]

I'm not sure about the ease of use in .Net

create GUI in .NET is very easy .... like VB, Delphi ...

[Ko Ko Naing]

Originally posted by somkiat puisungnoen:


create GUI in .NET is very easy .... like VB, Delphi ...

I've tried neither VB nor Delphi...

I used come from the system level programming language like ANSI C, C++, Lex/Yacc before I jump into the world of Java....

[Ben Ritchie]

I know some people think Swing is great, it can look good and it can be fast, but that's missing the point a bit.

The problem with Swing is that people keep on getting it wrong. It's not just that Swing is new, because it isn't any more, and, while things may be getting a bit better, Swing is still the cause of many horror stories with Java projects. If we assume that Java developers writing Swing applications are no smarter or dumber than developers working with any other GUI toolkit, then it suggests that Sun got Swing wrong from an ease of use point of view. Maybe that should have been the focus of Java 1.5 work, rather than a new theme?

[Ben Wood]

I use swing a little, but admittedly most of what I do is server side stuff so works through a servlet or whatever. However, I do think it's fairly easy to get _something_ up and running in a pretty short space of time with Swing, and I have done so on many occassions.

The big problems are the blurring of the territories between AWT and swing which confused me as a novice programmer. Also the sizing of components etc when doing the layout, as mentioned above, is deeply infuriating and can mean hours of tweaking to get things in the right place. The grid bag layout manager is a complete nightmare. The components are sometimes inflexible. Swing has good days and bad days, depending on what you're trying to do, but above all it doesn't feel particularly well thought out to me, I do think they need to revise it completely instead of bolting on new l&f's.

[Gregg Bolinger]

Warren Dew said: it had two major disadvantages:...

Both your disadvantages have everything to do with documentation and nothing to do with the Swing API.

Ben Ritchie said: The problem with Swing is that people keep on getting it wrong

I agree 100% And I know that I am probably getting it wrong. The problem is no one is telling us how to do it right. There are no books on proper swing coding techniques. All the Swing books I know about just cover the API, which I can get online. The underlying problem with this is that Sun hasn't specified a correct way. And they need to.

Thomas Paul said: My main complaint against Swing is that it is way too complicated to do even simple things.

Seems like I have heard this before. To an extent I agree with you. Windows Forms are a bit higher of an abstraction to GUI programming than Swing is. But only a little bit. So they have packed a bit more common functionallity into each widget assuming this is what most developers need from it, which is great. But what truly makes GUI programming with the .NET environment a pleasure is Visual Studio.

[Matt R. Hansen]

In a computerworld article, Gosling said:
"The big problem that Swing has is that it's big and complicated. And the reason that it's big and complicated is that it is the most fully featured, flexible, whatever-way-you-want-to-measure-it UI [user interface] tool kit on the planet. You can do the most amazing things with Swing. It's sort of the 747 cockpit of UI design tool kits, and flying a 747 is a little intimidating, and what people really want is a Cessna."

Sure, the 747 still needs some work, but Sun has a fleet of planes to take care of. And they do it at virtually no cost.

[Warren Dew]

Gregg Bolinger responding to me:

Both your disadvantages have everything to do with documentation and nothing to do with the Swing API.

I certainly agree they have everything to do with the Swing documentation. I don't necessarily agree that they have nothing to do with the API.

In the first case - the layout managers - the fact that the documentation is poor means we don't actually know what the API is. Without knowing what the API actually is, we can't actually tell whether it's any good.

For example, it's quite possible that the layout manager documentation is poor because the programmers don't actually know how their own code behaves. Many of the layout managers may behave the way they do because that's how they happened to be programmed, rather than because that behavior is the right way to do things. I think this is rather more likely than the possibility that there's really a clean API hiding there somewhere, and it's just that no one has figured it out yet.

If I recall correctly - and this was a while ago so the details are fuzzy - the second case was one where a modal dialog box method was advertised to block the thread and didn't. I would argue that what the documentation said - that the thread blocked - was the correct way to do it. The way it was actually implemented meant that it was impossible to actually get deterministic behavior for certain inputs, which limits the quality of the resulting application.

Of course, maybe it's just that I haven't figured out yet that some supposedly nonmodal dialog box, which is advertised to be nonblocking, actually blocks and the Swing programmers or documenters just got their functions reversed, and if I just used the function that actually did what I wanted, rather than the one that just said it did what I wanted, I'd be okay. But experimenting to figure out what things actually do is a big part of why programming in Swing is so inefficient.

[Ko Ko Naing]

Originally posted by Warren Dew:
In the first case - the layout managers - the fact that the documentation is poor means we don't actually know what the API is. Without knowing what the API actually is, we can't actually tell whether it's any good.

Do we really care about API documentation? The things that lies inside is the Swing itself, not the documentation... If we really needs help in understanding the API documentation, we can get a good Swing book and read the book instead of the API... I believe there are many out there in the market...

But experimenting to figure out what things actually do is a big part of why programming in Swing is so inefficient.

I'm not quite sure what you mean by programming in Swing is so inefficient... If we can catch up the good practices well in Swing, applications written with Swing could be efficient as well...

[Warren Dew]

Ko Ko Naing:

I'm not quite sure what you mean by programming in Swing is so inefficient... If we can catch up the good practices well in Swing, applications written with Swing could be efficient as well...

I'm talking about inefficient programming - as in inefficient use of the programmer's time - not inefficient applications. If it takes three times as long to program a good interface in Swing than in another package - in my example, the Macintosh System 7 interface - then the programming process is inefficient, no matter how efficient the resulting application is.

(Actually, the System 7 applications are extremely efficient in modern terms - after all, they were designed to run on machines that were only about 1% as fast as today's machines - but that's not the issue I'm getting at here.)

[Ko Ko Naing]

Originally posted by Warren Dew:
I'm talking about inefficient programming - as in inefficient use of the programmer's time - not inefficient applications. If it takes three times as long to program a good interface in Swing than in another package - in my example, the Macintosh System 7 interface - then the programming process is inefficient, no matter how efficient the resulting application is.

(Actually, the System 7 applications are extremely efficient in modern terms - after all, they were designed to run on machines that were only about 1% as fast as today's machines - but that's not the issue I'm getting at here.)

I got it... You are talking about the inefficient use of coding time...

Well, Swing might take long time to code, but it was designed to "Write Once, Run Anywhere"... Not like System 7 that you talked about, which I am not sure whether it can be run anywhere or not... But if it was desgined specifically for a certain system, then it might be run faster than Swing...