Skip to content
Print

Does Swing Need Saving?

21
Feb
2007

There’s been some discussion lately regarding various scripting languages and if they are (or aren’t) the salvation for the “dying” Swing API (here, here and here). However, all of these blog entries assume one critical fact: Swing is dead or at least dying. I call that assumption into question.

Actually, I was kind of surprised that none of the Sun fan-boys beat me to the punch. Over the years, I’ve shot my mouth of quite a bit against Swing. So it surprises me greatly that I’d be the first to step forward and try to defend Swing. In fact, if you had talked to me a year ago, likely I would have been leading the charge to bury Swing and move on. Apparently, some things have changed…

The first post to hit the blogosphere, JRuby can save Swing summed up the core assumptions of all three pretty quickly:

  • Swing apps are slow to build
  • Swing layout managers suck
  • Swing apps are hard to maintain
  • Swing is too powerful
  • No native features
  • Swing apps have a bad history

To start with, assuming that using Swing from within a scripting language solves any of these problems smacks of dynamically-typed delirium. When I first read the JRuby cannot save Swing post, I assumed that it would mention this minor fact, but instead it simply berated Swing further and proposed that it is “beyond saving”. Somehow, this seems a little bit of an extreme sentiment towards one of Java’s most established frameworks. Let’s look at item number one…

Swing apps are slow to build

That depends greatly on a number of factors, not the least of which is the capabilities of the developer in question. I can build a non-trivial Swing UI in a couple hours. I’m sure Romain Guy could do it in half that. Compare that to some developers who would take hours to build a simple, three element form. It’s all relative.

Some of the blog posts propose that using a dynamic language would help with this problem. Let’s take a look:

public class TestClass {
    public static void main(String... args) {
        JFrame frame = new JFrame("Test Frame");
 
        JLabel label = new JLabel("This is the header");
        label.setFont(label.getFont().deriveFont(label.getFont().getSize2D() + 10));
        frame.add(label, BorderLayout.NORTH);
 
        JPanel buttonPanel = new JPanel();
        frame.add(buttonPanel);
 
        buttonPanel.add(new JButton("Button 1"));
        buttonPanel.add(new JButton("Button 2"));
        buttonPanel.add(new JButton("Button 3"));
 
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setSize(400, 200);
        frame.setVisible(true);
    }
}

This took me about 3 minutes to whip together. Obviously this is a toy example, but it does illustrate the point that Swing isn’t that cryptic or bulky. Now, let’s take a look at the corresponding JRuby code:

require 'java'
 
JFrame = javax.swing.JFrame
JLabel = javax.swing.JLabel
JPanel = javax.swing.JPanel
JButton = javax.swing.JButton
 
BorderLayout = java.awt.BorderLayout
 
frame = JFrame.new 'Test Frame'
 
label = JLabel.new 'This is the header'
label.font = label.font.deriveFont(label.font.size_2D + 10)
frame.add(label, BorderLayout::NORTH)
 
button_panel = JPanel.new
frame.add button_panel
 
button_panel.add JButton.new 'Button 1'
button_panel.add JButton.new 'Button 2'
button_panel.add JButton.new 'Button 3'
 
frame.default_close_operation = JFrame::EXIT_ON_CLOSE
frame.setSize(400, 200)
frame.visible = true

Now, this took me just as long to put together as the example in Java. And I had already built the UI! Ruby is 1) a nice dynamic language, and 2) I had already done the work. Shouldn’t this have gone much faster? Also, this doesn’t seem too much clearer to me than the Java example. I mean, it’s all Swing.

One of the posts proposed that a generic (possibly XML based) overlay be created on top of Swing which would simplify development by only using Swing indirectly. Well, people have already done this (it’s called XUL), and it isn’t very popular outside of Mozilla.org But let’s move on…

Swing layout managers suck

Well maybe… It greatly depends on the type of UI you’re trying to create. If you’re trying to create a form-based UI with lots of elements then I will concede the point. The reason being that most forms are laid out in a grid-like fashion. For example, something like this:


It’s very hard to do something like this in Swing because the only two grid-based layout managers are GridLayout and GridBagLayout. GridLayout is extremely limiting, requiring all cells to be exactly the same dimensions, and GridBagLayout is powerful to a fault (as well as having some glaring weaknesses, like no absolute cell sizes).

However, this single shortcoming in the Swing layout manager menagerie (lack of a good form layout) has been rectified in Java 6. More specifically, the problem was fixed with the introduction of GroupLayout, which is the layout manager used by the NetBeans GUI builder (formerly Matisse). Although GroupLayout’s API is somewhat cryptic (not to mention Java 6 only), it’s still a very powerful layout manager, even more than GridBagLayout. There are also a whole host of third-party layout managers available for Swing which excel at form based layouts. JGoodies’s FormLayout is a popular one. I myself have even gone so far as to port a layout manager from SWT, GridLayout (which resembles GridBagLayout in power without the complexity). This brings me to my next point…

Even if there were no solid layout managers available for Swing, it’s still very easy to create your own. In fact, this process is so simple, and so revealing about the way Swing layout managers work, that I would recommend anyone who’s serious about developing with Swing to pursue custom layout managers. I’ve written several layout managers over the years. While I only use one of them on a regular basis, I greatly value the lessons learned from each and every one of them. And honestly, Swing makes the task of layout manager creation significantly easier than many other GUI toolkits (such as SWT).

Swing apps are hard to maintain

Not true. Badly designed code is hard to maintain. Badly designed code is written by bad programmers. Bad programmers are incapable of using Swing properly (and even if they did, the rest of their code would be atrocious). In fact, Swing encourages best-practice coding in a lot of ways (a highly MVC based architecture for one). If anything, Swing-based apps are easier to maintain than those created using other APIs.

Swing is too powerful

This is a problem?

No native features

Well, it depends on what you mean when you say “no native features”. Does every element in a Swing UI correspond with a native peer? No. Are Swing elements indistinguishable from their native counterparts? Eh, depends on the platform and how good your eyes are. On Windows XP, the answer is often yes. On Vista, less often. On Mac the differences are acceptable, but on Linux the GTKLookAndFeel is terrible. Don’t get me wrong, it’s better than it was, but it still needs a lot of work before it’s truly production quality.

The “native features” case in which Swing falls drastically short is in integration with the native platform’s desktop features. For example:

  • Determining and firing native apps for a particular file association
  • Retrieving corresponding icons for a certain file association
  • Determining file associations in the first place
  • Access to any sort of platform-specific feature
  • …and so on

I won’t deny that SWT is miles ahead of Swing in this regard. However, there is some dissention over a) are these really the responsibility of the GUI toolkit? and b) what’s wrong with separate libraries like JDIC? Oh well, we’ll still chalk this up as a point for “the other side” (whoever that may be).

Swing apps have a bad history

This is flat out undeniable. Swing apps have a terrible reputation. I still walk into random IT departments, mention I’m a Java developer and get lectures about how slow, ugly and unreliable Java is; when in fact, these comments are really directed at legacy Swing applications.

Swing is a hard API to use properly. This is true mainly because it is an API worth using. This difficulty that programmers have with Swing is amplified by the fact that back in the day, many GUIs were designed visually with the aid of tools like Delphi or Visual Basic’s form editor. Obviously, these tools make it a lot easier to get a “cheap and dirty” UI out the door quickly, but the result really isn’t a GUI worth maintaining. Also, it led to a lot of bad programmers thinking that they were good programmers because they were able to create mediocre prototypes. Refer to “Swing apps are hard to maintain” for more on this point.

Also, until recently, the look and feels available for use with Swing were either highly esoteric and non-native or flat out ugly (or both). Without a solid look and feel to render the components well, Swing looks terrible. However, as of Java 5 Swing got a vastly improved Luna (Windows XP) look and feel. Java 6 introduced a half-way-there GTKLookAndFeel on linux, as well as sub-pixel rendering. Swing fonts have been the focal point of a lot of criticisms primarily because they (until recently) lacked sub-pixel rendering. (sub-pixel rendering allows fonts to look “smoother” on most screens) I think that you could make an argument that Swing on Windows XP looks just as good as any native application.

To Conclude…

Swing is in no need of a rescue from more “hip” languages like Ruby or Groovy. Nor is Swing languishing in the pit of unattractiveness. Rather, Swing is alive and well, and getting stronger by the day. Swing doesn’t need saving, what Swing needs is to be given another chance by the world.

Comments

  1. Well, here’s an alternate approach to that small app, taking advantage of “builders” in languages like Ruby and Groovy (formatting will probably get lost, but you get the idea):

    require ‘java’

    builder = SwingBuilder.new

    builder.frame(“Test Frame”) {
    label(“This is the header”, NORTH) {
    self.font = self.font.deriveFont(label.font.size_2D + 10)
    }
    panel {
    button “Button 1″
    button “Button 2″
    button “Button 3″
    }
    self.on_close = EXIT_ON_CLOSE
    set_size(400, 200)
    set_visible(true)
    }

    And you can start to see why a dynlang could make Swing even more palatable. Groovy already has a builder like this, and there’s a number of possible builders for JRuby. Dynlangs *do* make it easier to work with APIs like Swing.

    Don’t get me wrong…I agree with your points about Swing itself. But to say that dynlangs don’t buy you anything is incorrect.

    Charles Oliver Nutter Wednesday, February 21, 2007 at 9:38 pm
  2. Um, ‘Swing layout managers suck’, lets change that line to:

    ‘JGoodies layout manager rocks’.

    The example form you have above, I create at runtime simply by adding rows to a couple of tables and voila, laid out perfectly. See the pictures on http://www.osrmt.com/gpage4.html. I did not create any of those forms by hand, and users can customize, add, remove, change number of columns, all through configuration forms (which incidently were built in the same way, and can be controlled in the same way, the recursion gets confusing…).

    Aron Smith Wednesday, February 21, 2007 at 9:51 pm
  3. @Headius

    Re:the formatting: Too bad it got lost in the presentation on the comments page. The email notification shows it quite well. :-)

    I have considered writing an API like the one you described. Ironically, almost line for line the same. Weird.

    It would really depend on the API used with the dynamic language as to the benefits thereof. You could right an API very similar (albeit with significantly more meta-syntax) in Java.

    daniel Wednesday, February 21, 2007 at 11:03 pm
  4. Good article, and lots of sound points to back them up. I think your point about taking the time to understand the guts of layout managers was spot on.

    I think what you should have also added about bad programmers was
    -bad programmers don’t know how to use google, to find the enormous amount of swing examples out there. But they’ll take the time to post to a forum for help
    -bad programmers don’t know how to attach source to look at the guts, or don’t even bother.

    Btw — I did a quick flick through dzone…did you submit the link?

    Stephen Thursday, February 22, 2007 at 2:03 am
  5. @Stephen

    Nope, I haven’t submitted it to dzone. I’ve kind of got this odd, manic aversion to submitting my own content, so I usually let other people do it if they think it’s good enough. :-)

    Good comments. Google is a very under-appreciated development resource. Every developer should be required to learn the ins and outs of the search syntax and how to optimize your query. Most people just mash down on the keyboard and scroll through pages of results. Good programmers refine their queries to the point that they can “feel lucky” almost all the time.

    daniel Thursday, February 22, 2007 at 3:14 am
  6. Hey,

    I agree with your comments, however i’m not sure VB and delphi apps are at fault for creating this impression that Swing apps are hard to develop, slow or anything else. For me the fact that the Intergrated Development Environments have for far too long been holding Java back, i now use Netbeans and with the UI designer baked in, i can build UI’s visually and quickly just like those VB or Delphi developers could, back in the day.

    I honestly belive that if Netbeans (or Eclipse) had been around 4 or 5 yesrs ago, Java on the desktop would be regarded much higher in the minds of those (uneducated) people who constantly knock Swing (and Java generally).

    Floyd Price Thursday, February 22, 2007 at 4:49 am
  7. Just a note that “dynamic” languages, in the sense of languages using dynamic type checks, are not uniquely suited to making Swing development quicker. F3, a statically typed language (think code completion), does pretty slick Swing without much effort:

    import f3.ui.*;
    Frame {
    title: “Test Frame”
    width: 400
    height: 200
    content: BorderPanel {
    top: Label {
    text: “This is the header”
    font: Font {
    // don’t know the language well enough yet
    // to use deriveFont here…
    size: 23
    }
    }
    center: FlowPanel {
    content: [
    Button {
    text: "Button 1"
    },
    Button {
    text: "Button 2"
    },
    Button {
    text: "Button 3"
    }
    ]
    }
    }
    }

    Jesse Glick Thursday, February 22, 2007 at 8:34 am
  8. @Floyd

    Actually, Eclipse and NetBeans *were* around four years ago (I was using them). However, they were mere shadows of the tools they are today, so in some respects I agree with you. Decent IDEs for Java have been slow in coming, as innovation and development progressed. What makes me very happy is that four years from now, we will have really really cool IDEs that are as much better than Eclipse 3.3 as Eclipse 3.3 is better than Eclipse 2.0

    @Jesse

    I’ve heard about F3. I have to admit, it’s a pretty clean way of building a Swing GUI, but what happens if you add events into the mix? I mean, my examples had no event handling, so I sort of cheated. But what does F3 look like if you have to handle dynamic events?

    daniel Thursday, February 22, 2007 at 10:26 am
  9. I’m the author of the original, original, original blog that kicked this all off (written several years ago, I might add). I would just like to clarify that when I say ‘layout managers suck’, I mean all layout managers. Or rather, the concept of a layout manager sucks. There’s nothing wrong with having a programmatic pluggable way of doing layout, but that’s an implementation detail. Application developers should be using a visual tool for doing layout. I don’t care whether it’s XML or Java code or generated Lisp under the hood. The developer should be able to use a visual tool. Layout is a visual task. Use a visual tool. End of story.

    Joshua Marinacci Thursday, February 22, 2007 at 11:02 am
  10. I knew you were going to say that ;-) but yes i’m talking about the IDE’s as they are today.

    MS Visual Studio 2005 is still miles ahead of Eclipse and Netbeans (for desktop application development) in my opinion, which is a real shame.

    Floyd Price Thursday, February 22, 2007 at 11:07 am
  11. @Josh

    If there really were a decent tool that could build decent GUIs in a production setting, I’d use it. But every tool I’ve ever used has collapsed pretty quickly under real-world pressure. Matisse is close, but being unable to tweak the UI by hand is a real killer. VE isn’t bad, but it’s tooling support isn’t as thick as it could be, so some stuff is a little contrived.

    But really the place where just about every tool falls short is with custom components. Matisse isn’t bad in this area, but I have yet to find a GUI builder tool which really handles custom components (non-delegate based) well.

    daniel Thursday, February 22, 2007 at 11:22 am
  12. Just a plug for JFormDesigner. http://www.jformdesigner.com/

    In my mind, it’s a fantastic swing gui designer, quite flexible, easy to use, handles custom beans (visual and non-visual), etc.

    I agree 100% with your post. The Swing API is powerful, and sorry to say, that intimidates a lot of folks, especially the ones with a VB background.

    Adam Taft Thursday, February 22, 2007 at 12:48 pm
  13. We’ve struggled with this for some time… and it’s certainly the case that building a simple form is a pain in Swing. Our experience with SimpleCenter is that it’s definitely possible to build nice looking applications, but it takes a lot of work.

    Lately I’ve been thinking that a better merging of web technologies with Swing would serve us well. Even desktop applications have strong ties to the web, and there is so much development going on in that area. Building some of the app using HTML and JavaScript might end up making sense, at least for the simple stuff. Unfortunately, Java’s HTML rendering is pretty horrid, but it sounds like that might be improving in Java 7.

    Jon Nichols Thursday, February 22, 2007 at 1:41 pm
  14. Swing, like SWT, is dying because on can’t reasonably integrate Java desktop applications into a particular desktop and operating system. It is not the GUI toolkit, it is the overall lack of integration.

    This starts already with installation. Java doesn’t interact or conform to a platform’s native software installation system. It continues with standard Java’s inability to identify things and places. Like, for example, removable media (and their absence or presence, mounting and unmounting), special directories, remote drives and similar. It further continues with standard Java’s inability to communicate with typical hardware interfaces on desktop machines, like, for example, USB, FireWire, or RS232 (yes I know). Not to mention that Java is bad at dealing with AV media, something which is nowadays a big desktop issue. And then we need to talk about access to desktop features. Like, for example, placing shortcuts and notes on the desktop, integration into the desktop’s main/application menu, registration of application-specific file types and file-type handers. Did I mention printing? Three APIs and still a PITA.

    We could then move to more obscure features. For example, on some platforms dialog confirmation buttons are by default presented in the order “[Ok] [Cancel]“. On others it is “[Cancel] [Ok]“. Where is Java’s support to determine a particular platform’s button order and/or to automatically arrange buttons in the system’s order? Where is Java’s feature to decide if a platform by default has scroll bars on the left or on the right side?

    What Sun fails to see is that desktop integration is more than just placing gray rectangles on the screen and allowing the user to move them around with the mouse. It is about having control over the whole system that sits on or under the user’s physical desk.

    It took ten years to finally get a standard API to access system trays. It took ten years to finally get an API to provide a right-sized application icon instead of having Java’s scaling algorithm convert your icon to pulp. Oh, and we finally got splash-screen support to “better” cover up the slow VM startup. If Java improvements for the desktop continue at that pace, oh well …

    Beine Undar Thursday, February 22, 2007 at 2:24 pm
  15. I definitely agree that writing a layout manager, even a simple one, will make you a much better Swing developer. I wrote a vertical form of FlowLayout, and the things I learned from doing that are still paying off, even using Matisse.

    As for the person who said UIs should be build with visual builders, that’s the same reasoning that made everyone who used MS FrontPage a “Website Designer”. If you want to visually design a UI, fine, do it on paper, or in Photoshop, or some other graphics program, then let a UI Developer turn that image into code. Generated UI code will never be as clean and flexible as UI code written by a good UI Developer.

    Michael Thursday, February 22, 2007 at 2:36 pm
  16. Please give valid reasons.
    The “native features” case in which Swing falls drastically short is in integration with the native platform’s desktop features. For example:

    * Determining and firing native apps for a particular file association
    Look at the new Java Desktop API
    * Retrieving corresponding icons for a certain file association
    FileSystemView.getFileSystemView().getSystemIcon(file)
    * Determining file associations in the first place
    * Access to any sort of platform-specific feature
    You’re right
    * …and so on

    Carl Antaki Thursday, February 22, 2007 at 6:31 pm
  17. I am a Swing developer of 8+ years. The biggest problem I think I face is that there is no standard way of spawning multiple swing apps under one JRE. If a client runs 3 swing apps, from three different vendors, three JRE processes are spawned.

    No one has that kind of RAM to run five to seven swing apps simultaneously, at least in 2nd world and 3rd world countries.

    There are efforts like Poor man’s Multi-VM by F3 author, but until there is a standard way of reducing the footprint, Swing would only end up being GUI API for specialized applications.

    Vinay Thursday, February 22, 2007 at 11:06 pm
  18. Swing apps are slow to build:
    Your little toy example proves nothing, you try developing a real application where you need a datepicker, undo mechanism, treetable, systray etc. Developing a Swing app takes at least twice as long as i.e. .NET, this has been observed many times in the organization I work for. And no, we are not .NET developers, it is only an escape route.

    Swing apps are hard to maintain:
    Your counter point raises another issue, they are hard to write in the first place. In order to use Swing, you need to have a masters degree and 10 years of experience with adaptor, command, mvc, singleton, iterator, builder etc. And then obviously you can do little without threads in Swing so that also complicates matters.

    Swing layout managers suck:
    Yes Matisse rocks. It took only 10 years and 15 attemps and then finally the .NET mechanism was duplicated in GroupLayout. Microsoft did not live in vain.

    Swing is too powerful:
    It means Swing is over engineered, there is a distinct lack of components which simply work which is what 90% of Swing developers really wants.

    No native features:
    Yes, too bad SWT did not merge into official Java and replace Swing. Unlike Swing, SWT renders perfectly to the native L&F (which is what the user really wants) and is a stronger component model. Hardcore Swing hackers would be annoyed, but they account for a small percentage.

    Casper Friday, February 23, 2007 at 3:36 am
  19. Vinay, if you’re really longing for a “multi-VM” then you should really have a look at the OSGi framework. On this framework, you can dynamically deploy, undeploy, start, stop and update bundles.

    You could make your Swing apps OSGi bundles, which is very simple – it means just adding a few lines to the manifest file in the JAR file that contains your Swing app.

    There’s an interesting tutotial series running on EclipseZone about OSGi. Check it out: http://www.eclipsezone.org/eclipse/forums/t90365.html

    Jesper Friday, February 23, 2007 at 7:39 am
  20. @Casper

    Obviously they’re toy examples. :-) However, I think you’re taking that little fact to a slight extreme. One point at a time:

    .NET apps are faster to build than Java. Obviously. However, look at the final result in the UI. Maybe it looks good, but what if you just resize the window? Noticing a slight problem are we? My point is that Swing apps are somewhat slower to build because there’s so much more to build with – much more power.

    Swing apps are hard to maintain. I don’t have a masters. I haven’t been in the field for 10 years. And I don’t have a problem maintaining extremely complex, multi-threaded Swing based applications. Nor do I have a major problem writing complex Swing applications. The problems I have really relate to some basic issues about hand-coded UIs.

    Matisse rocks. Eh, seem my post about visual gui builders for my opinion on that one.

    SWT merged into Java. This would be a disaster, both for Java and for SWT. SWT because it could no longer be updated independent of the VM. Java because it would lose it’s most powerful GUI development toolkit (Swing). SWT is all well and good (and a wonderful API), but it has it’s weirdness, it’s limits, and it’s flat-out annoyances. In the end, I kind of like SWT as a third party API which I can use if I so choose, and ignore otherwise.

    daniel Friday, February 23, 2007 at 10:56 am
  21. Thanks for the tip Jesper. I heard of OSGi several times but didn’t care to know about it.

    Anyhow, Swing including the Layout managers are just great. No complaints with the intuitiveness, power and free 100s of free components. Just a little less crisp than SWT apps but that has improved as well. Hope it gets better with time.

    I will give OSGi a try.

    Thanks,

    Vinay

    Vinay Saturday, February 24, 2007 at 12:12 am
  22. Thank you! Ive been looking for an article like this! I HATE it when people can Java slow and buggy, when It all depends on the developer!

    JavaGuy147 Saturday, February 24, 2007 at 12:58 pm
  23. Being a java developer, I too find some annoyances with my favorite programming language:
    - Swing development (Matisse is good but code produced untouchable and unreadable)
    - Swing not thread safe
    - Big signature, slow loading, etc

    I think it would be a nice idea to have a global place to keep our complaints, get them prioritized and make JSRs for solving them.

    Monty Sunday, February 25, 2007 at 7:40 am
  24. This quote goes on the swing bad history

    “Seriously, whenever anyone wants to start programming Swing someone else needs to get a stick and beat them until they write in blood the oath “I will not do data processing in the Event Dispatch Thread.”
    :)

    igor Monday, February 26, 2007 at 6:34 am
  25. swing is a fantastic GUI,and big corps. that use custom software solutions don’t care about LnF – as long as the app does it daily job well – then so what if it looks ‘ugly’? JAVA software is ROCK SOLID why do u think its done so well in the last 10 years?
    the cricticism is based against commercial ‘off the shelf’ software , yes , METAL LnF is a big ugly,but take a look at some well made apps that use SWING – JBUILDER for example,its GUI is a bit slower than say a similar VISUAL BASIC GUI but the fact is once you start to use the software you quickly forget all about it.
    I am unsure why SUN has been so slow in providing better integration with the NATIVE look and feels but one reason may be is that SUN under the very nature of JAVA must provide a coherent LnF for ALL the pltforms it supports.

    wahid Monday, February 26, 2007 at 7:25 am
  26. Obviously this is a toy example, but it does illustrate the point that:
    1) it is far easier to write a Swing program that violates the EDT rules than one that doesn’t
    2) Swing doesn’t have adequate support for separating UI design from business logic

    See also Swing Helper
    https://swinghelper.dev.java.net/

    Curt Cox Monday, February 26, 2007 at 7:25 am
  27. Hi every body, in university i developed some awt demos, the main problem
    was lack of memory to use a IDE to building the gui so to many try/error
    for positioning well the controls. latter in laboral life i started with
    web development with jsp, struts, ejb2, ejb2 sucks, jsp a little too,
    what pain i suffer, no oo model (request/response) paradigm, impossible
    to apply oo principes, code reusability, or at least structured programing,
    differente support of browser of standars, what painful it is. Latter in
    another job i work with swing what a relief, (Jdeveloper) two applications in one year using Java Web Start, Aqua look and feel, the main disavantage was
    that was client/server, uses 50 Mb of memory (after optimizing from 120).
    too much memory for some winxp cliente wit 128MB RAM. luckly all important
    clienta had 256MB RAM. Latter i developed again with JSP until now, however
    i always remeber those days, a pure language, no mix. Compared to my
    previus experience it was easy than jsp, belive me, and i did’t know
    about patterns and anything like that.

    That look easy to develop, but add some custom behavior and it
    will look like a monster, also how many web frameworks there are
    to try to resolve problem of difficult web programing?, in
    the other side swing and SWT.

    Now for the
    new rich clients, new options appear AJAX, Flash, i will prefer
    a come back of swing, (client/server) problem is easily to solve
    with webservice (html/soap) so swing clients doesn’t need to load a big
    jar all the process could be done in the server, and swing only needs
    to display data with this memory usage and initial download size could
    be reduced (25MB memory, 1mb jar) , a easy/clean install of java should be needed also
    (for me java is easy to install than flash, but many peple say that is
    difficult), Shared JVM should help also, and thats it, i hope
    Java 7 could bring us that, otherwise i wich shift to flash.

    aldo Monday, February 26, 2007 at 4:49 pm
  28. @Curt

    Yeah, I kind of ignored the EDT. I probably should have brought it up since (without my helper method) it’s much uglier to force EDT operations in JRuby than it is in Java. Oh well. :-)

    Daniel Spiewak Monday, February 26, 2007 at 4:52 pm
  29. The most singular problem w/ the EDT issue is that developers do not understand multi threading. It’s a symptom of another debate…RAD tools + good higher level apis = developers don’t have to understand the internals.

    In WinForms, you have to do data processing outside the GUI thread as well, and I’m sure this is the case for Objective C.

    I believe someone wrote an article that made dzone comparing the three(I’m a bit too busy to search at the moment)

    My main point is EDT problems are not exclusive to Swing; they are just known as something else.

    Stephen Tuesday, February 27, 2007 at 7:20 am
  30. swing font is really really ugly, i think it hurting my eyes.
    can’t imagine others will use my product is i choose swing.

    stevpan Friday, March 9, 2007 at 3:32 am
  31. could sun guys turn out somewhat goodlooking interface?

    stevpan Friday, March 9, 2007 at 3:33 am
  32. Very nice article, and I agree most of the comments. Your approach to the subject is nice and rational

    İskender Yigitel Thursday, May 17, 2007 at 9:13 am
  33. Having used Visual Studio for years… I’m totally baffled by Java’s layout managers.

    I have never come across a limitation in building a GUI in Visual Studio, and the GUI creation process has always been a non-issue, a quick 30 seconds before you really dig down into writing the application’s code.

    Java’s layout managers on the other hand – are all ridiculously laborious and limited.

    Java Sucks Sunday, May 25, 2008 at 1:27 pm
  34. By contrast, Visual Studio produces UIs which don’t reposition (on frame resize), aren’t cross-platform friendly, and are *incapable* of resolution independence. You lose a lot when you go with absolute positioning for everything. It works for some apps, but I’m glad that Swing (and SWT) took the high road and used layout managers.

    If flash/bang is what you’re looking for though, you should try Matisse. For most simple to moderately-complex UIs, Matisse is capable of producing the Java code with full layout management wrapped by a tool which is (I believe) even easier than WinForms designer.

    Daniel Spiewak Sunday, May 25, 2008 at 6:44 pm
  35. Regarding the appearance, Sun introduced a new one recently called “Nimbus” which is a major improvement over “Metal” and I’ve gotten good feedback from some novice users about it — it looks nice, modern, is easy to use, and even has a minor quirk (as all good things usually do) in that the scroll bars look partly rounded (this seems odd at first, but users seem to get used to it really quickly and take quite a liking to it).

    Randolf Richardson Sunday, August 8, 2010 at 12:06 am

Post a Comment

Comments are automatically formatted. Markup are either stripped or will cause large blocks of text to be eaten, depending on the phase of the moon. Code snippets should be wrapped in <pre>...</pre> tags. Indentation within pre tags will be preserved, and most instances of "<" and ">" will work without a problem.

Please note that first-time commenters are moderated, so don't panic if your comment doesn't appear immediately.

*
*