Arrrrrgh, Swing!

[cfmdobbie]

Why is everything so blooming hard to get right in Swing?

Why are there no decent layout managers?   I used to think GridBagLayout was the biggest and best, but its mysterious rules about component widths (that Sun seem reluctant to explain) just mean it's a pig to work with.  Why, when CSS gets everything done in one place, do we have any more layout managers than one?

Why is there no feedback about why something is behaving in a certain way?  I refuse to accept that the core API is developed without any logging at all - that would just be stupid - and suspect it's conditionally-compiled out of each release.  Why can't I get hold of a debug-enabled build?

Why do seemingly trivial settings cause massive changes throughout the GUI?  Why do I have to dig into the API source to discover why turning on line wrapping on a JTextArea causes fundamental changes in component layout?

Why does there seem to be no consistency in component layout?  Why are there funny little border cases all over the place where moving something 1 pixel to the left causes the layout to change by 200 pixels, or more?

Why is the Swing documentation so poorly maintained?  Why is the Java Tutorial positively littered with [PENDING] comments?

Why did Sun even bother with HTML support?  Things were added with no attempt to make them appropiate for a GUI, and I've never managed to find any useful documentation on any of it.  It's almost as if it were included for the sole purpose of being buzzword-compliant.

Why does it often seem like half the API is missing?  Given the existence of layout managers that ignore e.g. heights, why am I forced into providing a (dummy) height when I want to set a minimum width - where's the setMinimumWidth() method?

Edit: And why oh why oh why does it seem like nothing respects minimum/maximum/preferred sizes?  Is it really too much to ask to have a text box with arbitrary text in it that stays at the size I set it to?


Is it just Swing... or are all GUI toolkits this bad? :-/

[Virum]

You aren't the only one.

Have you thought about giving SWT (I think) a try?  Eclipse "uses" it for its GUI; it seems nice enough.

[JasonB]

Is it just Swing... or are all GUI toolkits this bad? :-/

I recently wrote (well half-wrote, haven't quite finished it yet) a text editor in python+gtk.  To be honest, I preferred it to Swing, but I don't think it was particularly straight-forward either.
In my experience, GUI toolkits seems to inhabit a black or white space (i.e. very few shades of grey). They're either simple to use, and therefore a bleedin nightmare when you want to do something complicated; or complicated as hell, and end up giving you just enough rope to hang yourself...  

Games published by our own members! Check 'em out!

[princec]

SWT's just as shit.

Cas

[Virum]

SWT's just as shit.

Cas

That's too bad to hear.  Thanks for saving me the trouble of trying it.

[cfmdobbie]

Well, damn.  I might just move into goat-herding instead.

[Grazer]

When developing swing apps, I don't start until I've included the following libraries.
If Swing is the toolkit, these are my power tools.  
They don't remove all the woes, but they make a lot of things a lot easier.

Disclaimer:
The first two libraries are written by a work colleague of mine.
I do use them, and they are really good, otherwise I wouldn't recommend them.
The last library is my own creation.
Neither he nor I get any money from any of them.

Layout: Explicit Table Builder
Awesome "builder" (i.e. facade) over Explicit Layout that makes building layouts on a table structure (which covers pretty much anything that's designed correctly) really easy.

Action Logic: GUI Commands
An extension of Swing's "Actions" that makes the concept useful. Basically, you write your business logic in a Command, and then ask that command for a component (e.g. button, menu item, whatever) that connects to the command. Sounds weird, but once you use it, it makes a whole lot more sense than having anonymous ActionListeners all over the place.

Look & Feel: JGoodies Looks
Really good looking Multi-Platform L&F. Also has a really accurate (supposedly) Windows L&F emulation. (I use the multi-platform 'Plastic' look).

Threading: Foxtrot
Lets you execute time-expensive code from the Swing Event Thread while allowing other events on the Event Queue to keep pumping. Just brilliant. Have a look at the examples if you don't understand.

Logging: Simple Log
18K logging library that's really simple to use and works with essentially no configuration. Lots of features, though.

[zingbat]

Swing is huge and slow and not very flexible. I wonder why they call it Swing at all. It should have been called Fat Joe instead.

[Grazer]

Swing is huge and slow and not very flexible.

That's a pretty derogatory claim to make without any justification.
I'd like to hear why you think this.
For what it's worth, here's why I don't agree with your sentiment...

Yes, Swing is quite large.
It is a large API, has a not-small memory footprint, and can take a while to load when an app first uses it.
However, Sun is working to reduce these problems with every release, and the improvements are noticeable.

Swing is not slow.
Many people have this impression because their limited Swing experience is with poorly-written applications that don't know how to use Swing.
In analog, if I pushed a Ferrari around a race track, that wouldn't make the Ferrari slow. It would make me naive.
It is easy to make a slow Swing application when you know nothing about its threading model.
When you actually know what you're doing, you can write fast, responsive, professional-quality applications on top of swing.
Commercial example: IntelliJ.
There are hundreds more examples of Swing being used in commercial production environments at Swing Sightings.
It wouldn't be being used for real applications if it really was slow.

Lastly, Swing is flexible.
It is extremely flexible!
I can't think of a reason why someone would think it wasn't flexible, so I can't really argue against the point.
But, in terms of flexibility, it is both customisable and extendable.
i.e. there are many places where you can change the specifics of how a Swing component works and, if you need something really different, it's pretty straight-forward to roll your own.
That's one of the very reasons that it's "huge", and also why many people find it complex when they start working with it.
As for me, I've always found a way to do what I want to do.
Sometimes it takes a bit of digging in the API, and understanding some aspect of Swing that I was previously oblivious to, but there's always been a way.

As I said at the top, I really would like to hear why you have the impression of Swing that you have, but my experience of real Swing applications is counter to your claims.

[princec]

One particular gripe I have with Swing is just how easy it is to write shit, slow code with it. And just how complicated and difficult it is to get just basic things looking right (not working right - that part's easy).


Cas

Games published by our own members! Check 'em out!

[zingbat]

I used Swing in one or two school projects of average complexity and spent some time working out bugs that weren't documented in the javadocs. That was 1.4 so i don't know if anything has changed in 1.5.

Just to give you some examples the best choice you have to layout components is GridBagLayout. To do the same thing you do with that layout you need to use other layouts like BorderLayout and BoxLayout and stack panels together in a very bodersome and memory consuming way. One problem i had was that GridBagLayout doesn't update Swing components properly. There is a layout that looks very good: its called SpringLayout or something like it, but every documentation on it is cryptic at minimum.

Another problem is the lack of documentation many areas that would be great to use like the HTML kit or the view objects. At the time i consulted the 1.4 documentation there were many places with entire methods and classes completely undocumented. Maybe this happens because classes are not reused much. Swing tree components use their own tree implementation and views use their own graph structure instead of using the container classes in java.util. This is bad use of the java object model.

Besides that the thing that bothers me most is the amount the memory consuption of Swing components. If you look at other gui solutions Swing guis consumes an absurd amount of memory that cannot be justified.

Yes i know that experts in Swing can do very fast and very good apps in Swing. You have Magicdraw UML as an example of it.

The point is Swing is just too much trouble for just  a simple gui, with all its omissive documentation, performance misteries. Its looks like Sun hired amateur ex c++ programmers to do it. There are books as big as an encyclopedia just to teach people how to work with Swing. This is bad for a gui api.

If you want my advice stay away from it. Sooner or latter there will be more complete guis based on one of the opengl bindings that will be much faster, economical and esy to use than Swing.

[princec]

Most of Swing's memory consumption is actually down to that daft huge double buffer. It's not all that inefficient when it comes to memory otherwise.

The documentation is pretty bad.

There aren't many useful shortcuts for the "90% of common cases" GUIs.

Cas

[zingbat]

I think that what people apreciate on Swing is how Sun created a gui that is very good following HCI (Human Computer Interaction) usability and accessibility principles.

The design principles for the java look and feel are almost Mac quality.

http://java.sun.com/products/jlf/ed2/book/

Its just a shame that all of this is wasted in a rather poor implementation.

[princec]

The more I look at Java's development over the years, the more I realise how fantastically underfunded and understaffed it is. To have taken this long to get to what 1.5 is, is just incredible.

Cas

[blahblahblahh]

That's a pretty derogatory claim to make without any justification.

Yup. You're right that for most things it's fast, and there's no *good* reason why any of it shoudl
be slow, but... it's also got slow crap bits.

Lastly, Swing is flexible.
It is extremely flexible!
I can't think of a reason why someone would think it wasn't flexible, so I can't really argue against the point.

Here's a good reason: Sun STILL HAVEN'T DOCUMENTED THE F***ING APIS THAT LET YOU EXTEND AND ALTER IT!!!

Try finding documentation on L&F's. There isn't any. Everyone's trying to reverse-engineer it from a JavaOne presentation a few years ago and from hacking on the java source.

(nb: this might, possibly, have changed inthe last 4-6 months. I very very much doubt it).

/me wonders why Swing has a bad rep...

[Chman]

Try finding documentation on L&F's. There isn't any.

And this ?

[Mark Thornton]

And this ?

Nobody reads design guidelines ... so perhaps the title ought to be changed.

[cfmdobbie]

Layout: Explicit Table Builder
Awesome "builder" (i.e. facade) over Explicit Layout that makes building layouts on a table structure (which covers pretty much anything that's designed correctly) really easy.

Action Logic: GUI Commands
An extension of Swing's "Actions" that makes the concept useful. Basically, you write your business logic in a Command, and then ask that command for a component (e.g. button, menu item, whatever) that connects to the command. Sounds weird, but once you use it, it makes a whole lot more sense than having anonymous ActionListeners all over the place.

Look & Feel: JGoodies Looks
Really good looking Multi-Platform L&F. Also has a really accurate (supposedly) Windows L&F emulation. (I use the multi-platform 'Plastic' look).

Threading: Foxtrot
Lets you execute time-expensive code from the Swing Event Thread while allowing other events on the Event Queue to keep pumping. Just brilliant. Have a look at the examples if you don't understand.

Logging: Simple Log
18K logging library that's really simple to use and works with essentially no configuration. Lots of features, though.

Interesting stuff!  I'll be looking further into these libraries for version two of my project - right now I just need things to work, they can work properly later.

The most recent class I've added to my project is a layout manager that only handles two objects: it gives 25% of the space to one, and 75% to the other.  It's bloody simple, and has solved all my layout problems.  I'm absolutely amazed that I couldn't shoehorn any of the current layout managers into performing this trivial task.  Ho-hum.

Dynamically-calculated minimum/preferred/maximum component sizes are a really good idea for a static GUI.  The moment you want to change the properties of a component at run-time, it becomes an absolute nightmare.

And this ?

I've read the look and feel design guidelines many times, and think they are very insightful on HCI matters.  Not at all helpful when you try and write an application using Swing, but great for designing the interface.

It's a damn shame that Sun have changed the default Metal theme in Java 1.5, violating many of the rules they themselves laid down when they wrote those guidelines.  Just because Microsoft promote a Fisher-Price GUI, doesn't mean chunky colourful widgets are at all a good idea.

[princec]

Why won't they just buy the Alloy L&F???

Cas

[Chman]

Why won't they just buy the Alloy L&F???

Cas

Dunno, but I must say that this one is impressive... I love it !

Chman

[blahblahblahh]

And this ?

That's not documentation. It's a marketing document to prepare interested parties before the product is ready.

It's ridiculous to offer it as LaF docs, since it has only ONE PARAGRAPH and a 3-way circular link in the glossary. It also has a very short appendix explaining how to switch the current LaF. Wow!

To recap: 0.000 documentation covering Swing LaFs. Except how to select one at runtime (and even that is incomplete!)