11

I have used Java Swing for some desktop applications. But I haven't used other GUI frameworks that much so I can't compare them.

There is definitely some things that I like with Swing and some that I don't like, but that is the situation with almost everything.

What are the biggest drawbacks with the Java Swing GUI framework?

Jonas
  • 14,867
  • 9
  • 69
  • 102
  • 2
    The question is interresting. I too wonder what are the strength and weaknesses of Swing, compared to QT, GTK, SWT, Winforms, Cocoa, and the like. Maybe you should rephrase the title to ask for *comparisons*, rather than *drawbacks* (which tend to bring not well-argued answers) – barjak Feb 14 '11 at 09:54

3 Answers3

3

  1. You have to have java installed somewhere. This is true of all GUI frameworks of course, but java has the perception of a 2 ton gorilla. It's gotten loads better, but those early java applet days turned a lot of people off. If you only need it to run your one app, it's a lot of maintenance to keep it up to date with security patches and the like. Everybody's gotta have Flash for youtube, .Net framework installs behind the scenes and everybody has javascript enabled on their browser. Java is usually an extra thing to do.

  2. All though it's sorta write-once, run anywhere, you still find that Mac OSX doesn't have this newfangled thing you want to use or one client refuses to upgrade their mandrake linux past JRE 1.4.

  3. As a dev, you have to think about threading. And it's in a tricky way, as multi-threading is possible but swing pretends like it's all single-threaded. But then half the libraries you pull in have some degree of multi-threading and assume that you know about EDT invokeLater and it forces a lot of lessons the hard way.

  4. Swing experience doesn't transfer easily to other kinds of UI development. For instance if you are a whiz at tables in .css, you're going to be completely waylaid by Jtables, renderers, editors, etc.

In general, the main problem with Swing is that it didn't live up to how it was marketed. It's a perfectly adequate technology for a lot of use cases, but those first 5 or 6 years were full of awful implementations and atrocious applets. And now it's old tech - on to Web 3.0 or whatever.

All that said, I do like Swing and think the pros generally outweigh the cons when you need what it offers. However the web experience is so ubiquitous now that many users are going to have an easier time with a web app than the most streamlined amazing swing app. And there are awesome Swing apps out there, but they don't seem to be mainstream.

Steve Jackson
  • 3,595
  • 1
  • 20
  • 27
  • 1
    I'm in the same situation than the OP : I know Swing and I'm interrested in comparing it to other GUI tooklits. For me, point 1, 2 and 4 are irrelevant to the question. So, I'd like to react to point 3 : could you give some examples of multithreaded GUI toolkits, please ? Thanks. – barjak Feb 14 '11 at 09:39
  • 2
    @barjak: Multithreaded GUI is a mistake. The only one I know of is the old Java AWT. But they learned from the mistakes when they designed Swing, which is single threaded as all modern GUI frameworks. – Jonas Feb 14 '11 at 10:20
  • @Jonas Making a developer think about multithreading is often a mistake, but you can't run animations, make RMI calls, or do intense calculation (this is a fat client toolkit, remember) without some degree of multithreading. – Steve Jackson Feb 14 '11 at 12:39
  • 3
    @Steve: That is true. But you should **not** do RMI calls and intense calculations in the GUI-thread. That kind of things should be done in a background thread, as in Swing and WPF. – Jonas Feb 14 '11 at 12:44
  • @barjak - Windows forms, MFC, SWT, pyQT, Juce....I'm having a harder time thinking of ones that aren't multi-threaded. The same rules generally apply though, you can't touch your GUI components except from the thread that created them. – Steve Jackson Feb 14 '11 at 12:47
  • @Jonas - Ah, I see where you're coming from. I was thinking in terms of GWT, where everything is exposed as single-threaded. Most other toolkits provide mechanisms for creating helper threads but sort of leave you on your own for not screwing up getting that info back to the gui that needs to display it. It's not hard, conceptually, but once you start pulling in other libraries creating threads you're not aware of, it gets ugly fast. – Steve Jackson Feb 14 '11 at 12:50
  • @barjak - I'm not an stackexchange expert, but you might get more traction if you ask your own question and link back to this one. Anyone who has the expertise you're looking for might skip over this one to avoid a fight. – Steve Jackson Feb 14 '11 at 12:52
2

Jonas,

Swing generalises your underlying architecture to provide you with a platform neutral user experience. The only heavyweight component (provided by the OS) is the JFrame container and the rest is pretty much handled by the Swing tookit. AWT on the other hard, asks the OS to draw all of it's UI components which means it's faster in a lot of ways as your using the native UI components specific to the OS. SWT tries to achieve a middle ground, for various standard components like buttons and labels (which are available on most OS), it lets the OS deal with those and for other specialised components, SWT will handle the creation for you.

That been said, I can outline the drawbacks.

(1) Since the toolkit creates and renders the components for you rather than asking the OS, you don't get to take advantage of the speed of the built in components provided by the OS.

(2) The UI isn't particuarly attrictive as it looks alien to most OS platforms regards of what look and feel you use.

(3) Some of the layout managers i.e GridBadLayout etc could be better simplified. I've lost count of the number of projects I've worked on where people have wrapped the GridBagLayout in some bespoke code to get a simpler way to use it.

I'd advise you to write a simple app in AWT, Swing and SWT and compare the development approaches an the final product between them all, then review the various comments made from other developers and decide which one works best. I've worked with Swing for many years and I used dislike SWT, but I'd come to realise that Swing is a lot more complicated than it needs to be when compared to other frameworks out there.

Desolate Planet
  • 6,038
  • 3
  • 29
  • 38
  • 4
    Swing is **GPU-accelerated**, which native frameworks isn't often, so I actually think that Swing is faster. This is also the strategy that WPF on Windows has but not WinForms (only on some versions of Windows). How can "[ugly]...regards of what look and feel you use" be true when it's very customizeable or you can use the platforms own LaF? I agree that the layout managers are really bad. – Jonas Feb 14 '11 at 21:48
  • Jonas, It's the "customizable" aspect of swing that makes it tricky compared to other frameworks. If you try to abstract away from the features the OS gives you, then you lose out on many of the benefits it offers. The very first version of Swing was a nightmare, which led to the creation of SWT in the first place. Later on Swing was improved to be a lot faster and you've got classes like SwingUtilities that offer better threading support for GUIs. – Desolate Planet Feb 14 '11 at 21:59
  • Ugly might be the wrong word; alien might be a better word as look and feel isn't exactly the same as the native UI look and feel, from what I remember, you've got Java, motif, metal and a few others, but in general, they aren't all that pretty. – Desolate Planet Feb 14 '11 at 22:00
  • The next thing to look at when doing a comparision is the effort involed in developing a UI. I would't say the layout managers are really bad, there better than no layout at all (which I have to deal with in work on a mobile device), but they don't make any effort to simplify the model. – Desolate Planet Feb 14 '11 at 22:02
  • I think based on what you've said, you have been using the more recent version of Swing, but when it first came out, people took a strong dislike to it and even more so when they tried to provide Swing based applets. There is a lot of history to the UI frameworks developed in Java and it's an interesting read if you look into it. – Desolate Planet Feb 14 '11 at 22:03
-2

Swing is slow (bad performance), hard/clumsy to use (compared to many other ones) and it doesn't look very good, in fact very bad, on some platforms.

Anto
  • 11,157
  • 13
  • 67
  • 103
  • 5
    I find it fast (it has GPU acceleration, compared to many native GUIs) so I can't agree with the performance or do you have any examples? How is it hard and clumsy compared to other frameworks? I agree that it doesn't look good but it can be configured to look like native apps or use a custom LaF. – Jonas Feb 12 '11 at 22:31
  • It looks more or less always non-native on GTK. What I have heard is that because it relies on Java 2D to draw widgets, it is slow, but I have nothing to prove that with. Both Qt and GTK feel less clumsy to me, but tastes differ. – Anto Feb 12 '11 at 22:34
  • Ah, it may perform worse on some platforms. I have only used it on Windows where it is GPU accelerated and very fast. – Jonas Feb 12 '11 at 22:43
  • 6
    People still complain that something doesn't look native, while using more and more browser-things (think: stackexchange), where every page looks different? And speed? Most of the time, an interactive GUI program is waiting for the user. – user unknown Feb 13 '11 at 00:58
  • 3
    Most "trendy" programs don't look native anymore. Swing ends up no better or worse in that regard. Performance of our 50kloc swing app (fat client) seems okay. Much easier to get swing to a point of not crashing than "native" applications. – Tim Williscroft Feb 14 '11 at 22:03