Java Swing 2.0

I believe that there is a need for a proper Swing 2.0 which is not JavaFX-based, but a true, desktop focused, Java (the language)-based framework. My vision is one shared by numerous others, and in a brief discussion (via twitter no-less), a number of us enumerated what we believe a Swing 2.0 needs. The following list is a brief overview of what Swing 2.0 should be:

  • Generics-based. No more should we put our objects into various Swing data models and components only to receive Object back. It should be possible to create swing data models and components with the data type specified. There is work in this direction already with the Swing-generics project, although progress is slow. Swing 2.0 should include this project instead of duplicating work.
  • Support for enumerations where obvious. There are numerous places where public static final ints could be replaced by enumerations. This leads to a cleaner API.
  • Support for varargs. Once again, there are places where varargs could be used to clean the API.
  • Improved support for collection frameworks. That is, we should not still be requiring Vector lists, unless syncrhronization is absolutely necessary.
  • Stricter enforcement of event dispatch thread (EDT) rules. Swing is slow (or so the saying goes). This is untrue, but is unfortunately the perception. This perception exists because developers don’t understand how to deal with the EDT. There exists code out there now that can enforce the rules surrounding the EDT by essentially throwing exceptions when components are handled off of the EDT, and when tasks take too long that should not be run on the EDT. By default, Swing 2.0 would enforce EDT checking, throwing all exceptions discovered. This may make developers unhappy, but the end result is better programs and happier users. It is worth it.
  • Improved support for bean binding and validation. I won’t go so far as to say we need properties, largely because I don’t know enough to have an informed opinion, and I know that by saying we need properties Swing 2.0 instantly becomes far less possible without major Java language updates. But, I know that projects such as the JGoodies beans binding and validation tools are very useful, and make creating data-driven user interfaces far easier and rapid. It may make sense to incorporate these kinds of frameworks into Swing 2.0 to enable users to focus on the business logic, and not getting data to and from the user.

What you may note is missing is any mention of new components, new Look and Feels, etc. That is not my interest – in my opinion Swing 2.0 is a cleanup of the code beneath the existing Swing components. It would be ideal if Swing 2.0 could be API compatible with Swing 1.0, but I would not be adverse to Swing 2.0 becoming a separate Swing library in its own package (i.e. javax.swing2). This would allow for API cleanups, and repurposing of existing API method names.

WhatΒ  do you think? Do we need a Swing 2.0 that has the roughly the above features (make any suggestions you have). Is it too little too late for desktop Java (personally I think not, obviously)? Please, leave any comments or thoughts that you may have – let’s get the discussion started.

178 thoughts on “Java Swing 2.0”

    1. You must be from the Winamp school of versioning πŸ™‚

      I’m not a JavaFX person yet, simply because my day job is fully Swing, and it will be for the foreseeable future. For this reason, Swing 2.0 is what I need, not JavaFX.

      I think it is very important not to confuse the general population into thinking JavaFX is Swing 2.0 – because it isn’t, and for that matter, shouldn’t try to be.


  1. Absolutely. I hope some of your ideas become reality. Especially your demands on generics, ease and clearness of thread use and property binding would make it a wonderful standard framework available at zillions of java installations.

    1. Thanks Ash. Hopefully we might get some momentum behind a Swing 2.0 vision, and perhaps something may come from it. But of course, before that, we need a good discussion about what Swing 2.0 means to everyone out there (and anyone that says Swing 2.0 == JavaFX instantly gets blacklisted πŸ˜› )

  2. I also support Swing 2.0 idea and more importantly the fact that JavaFX is NOT Swing 2.0.

    People use ( and love ) to make this confusion and IMHO Sun helps a lot making such misunderstanding.

    1. As I’ve said numerous times before, Sun would do well to employ a person or two whose job was to ensure consistency and clarity of message. Java versioning can be confusing (i.e. 1.5 vs 5, etc), the role of JavaFX and Swing (is JavaFX a Swing 2.0? is it for internet sites and/or for desktop applications? etc) is unclear, and there needs to be someone who either has the answers, or is the person who can give the definitive answers (after seeking from the relevant internal people). This is a role for someone able to talk to the community as well as talk to the technical people inside Sun.

      Anyway, back onto subject. Thanks to Somatik and Kenneth for your messages. It’s great to see the comments coming through. Do you have any suggestions on what you’d want Swing 2.0 to be, or do you pretty much agree with what I outlined in the post?


  3. Hello Jonathan,

    The things you mention is good to have for sure, but it doesn’t do that much for making Swing simpler to use, not counting binding and validation.
    Here’s a few additions that trip developers and make then spend hours trying and trying again:

    * Better handling of scroll panes. Components that should scroll should extend a scrollable component. This makes it easier to handle in its API. Of course a generic JScrollPane that you can wrap with should be there.

    * Better layout manager(s) (It just happens I know a good choice πŸ˜‰

    * Better handling of the validate/invalidate/revalidate/repaint mess. You should never have to call these as a developer, it should happen automagically.

    * Layered painting build in from the start. That way you don’t ave to sub class to customize. Layers should be able to handle events too so that you for instance can add a “disabled” layer over a specific component.

    * Components should be able to paint outside its bounds. This is so you can for instance add a drop shadow layer without having to change the bounds of the component.

    * min/preferred/max sizes should be width/height and not size. And they should take the size in the “other” dimension as an optional parameter, just like SWT. This is very important since it makes the job of the layout manager so much easier. No more wrapping problems in TextComponents.

    * Real properties. JGoodies’ binding is great but it lacks refactor survivability. We NEED real properties. I’m not talking simple replacement for getters and setters.

    * All value classes such as Point, Dimension, Rectangle etc. should be immutable.

    * I know there is more… Much more..

    And finally. Saying that JavaFX is Swing x.0 is like saying that MFC was win64… πŸ˜‰ That doesn’t take anything out of JavaFX though, it’s just a different beast.

    Mikael Grev

  4. Swing 2.0; I just realized I’m kinda building it myself. Already have the JTextField extention with generics (JFormattedTextfield alternative). And varargs for constructing the horizontal panels and the like. So yes, we do need Swing 2.0. And the points you make here are to be included.

    However, I already have the EDT checker in my swing projects. I already use JGoodies binding. I’m already using generics and varargs. So these are no brainers to include; that could/should be done in the application framework.

    Personally my problem is more with the components itself; they are complex to use for anyone not very skilled in Swing. One needs to add listeners to all kind of “weird” models (SelectionModel, ListModel, etc). And the events being fired are not practical for binding, so there are all kind of “yes-but” things when trying to bind.

    So IMHO we indeed need a Swing2.0, but as a fresh library with well thought through components, written with the coder actually using it in mind. MVC is great, but should be an implementation detail, there when you need it, but not fully exposed. Swing core is just fine.

  5. Swing 2.0 is a great idea, especially when sun continues to try and tie javafx development to netbeans ( a persistent bee in my bonnet ).

    Is there and easy way we can get this started ? A project perhaps ? It also strikes me that the earliest versions could simply wrap over the top of the existing swing classes ?

    You’d need a better name than swing 2.0 for packaging – perhaps one of’s synonyms ? I’d go for javax.rock simply because it would.

  6. OK, I remember a few more..

    * All Components shouldn’t be Containers. There is no reason a button should be able to hold other components. Especially since layers are there. SWT and .NET got this right.. Basically this means fixing the hierarchy that was complicated when Swing extended AWT back in the days.

    * All listeners should be single method interfaces so they would work well with CICE (or BGGA). You should switch on the type. That would mean easier extensions when new type becomes available.

    * Better thought out listeners. Now there’s a zillion different listeners and many of them overlap in concept.

    * JavaBeans 2.0. This is almost as important as Swing 2.0. It would mean super great handling in IDEs and much easier to write components that would work in all IDEs.

    * A single Window ancestor that is actually used in the API (Frame vs Dialog vs JFrame vs JDialog vs Applet vs JApplet vs Window problem).

    * Much better handling of Z-order of both components and top level windows. For instance you can’t today change/control the Z-order of top level windows except by making a Window a sub-window to another window.

    * Using Paint instead of Color everywhere. Return Graphics2D (or a new one with the old obsolete methods removed. Java2D is great but some of the classes use old and dated API).

    * Adhere to the transparency of Colors. Setting the background to new Color(x, y, x, 128) would make the component’s background transparent without artifacts. No isOpaque()/setOpaque(boolean) debacle.

    I don’t promise there won’t be more… πŸ™‚

    Mikael Grev

    1. Dang, I had a long response to everyone get lost….ok, brief response time:

      @Michael: Couldn’t agree more with almost all of your thoughts. The only reason I don’t push for properties is the requirement to change the language, which is obviously a rather large hurdle when all I’m pushing for at the moment is a better Swing API. Regardless, thanks very much for all your input – these are all so important to get right, so I much appreciate your thought – keep the ideas rolling in.

      @Tbee: That’s really the whole point I guess – what’s the point in everyone having their own ‘Swing 2.0’ when a collective, agreed upon release could be so much better. I tend to think the current event model in Swing is very good, but there is scope to look out for overlapping event listeners and to overall clean out the API.

      @Paul Loveridge: I think we don’t move much further than discussing on this blog now. Perhaps in the next day or two we can entertain this idea, but there is no point racing into things yet. I would really love to get a proper discussion rolling with Sun about the topics discussed in this blog post before we jump headfirst into a very big project!

      Overall, thanks to everyone giving thought to this problem. Only through your comments and ideas can a Swing 2.0 ever become realistic. Ideally we’d get our voice heard within Sun, and maybe some thoughts from their way. Lets hope so, for the sake of Swing.

  7. @Christophe Painters would need discussing – I only know a little about them in the context of SwingX, but not enough to say yes or no absolutely (in my opinion). What do you think – are they something that should absolutely be part of Swing 2.0, or are they a sideline feature?

  8. Should Swing 2.0 break the backward compatibility with Swing?

    Don’t start with what feature you would want to add. This is the central debate.

    Swing 2.0 should improve the components API, there are too many features missing in the current API especially in the JTable, you just have to check the hacks needed to build the SwingX JXTable to make the highlighting and filtering work to be sure of that.

    So the real question should not be shall Swing 2.0 be done inside or outside JavaFX. The real question is do you think Swing 2.0 should break the backward compatibility.

    If yes then JavaFX is a place where it can be done, if not then you are stuck with the current API and the features that can be added won’t answer your need.

  9. Painters are used as layers in a component. It’s like a super super light component that is basically just a paint() method (and possibly a processEvent(Event e) method). They are used to paint components. For instance a Button might consist of a backgroundPainter that paints the background. A contentPainter that paints the actual button look. A foregroundButton that paints the text. This way you can for instance easily wrap the text and make it blurry and have this work with all Look&Feels.

    It makes it less probably that you need to subclass a component to change the look and even if sub class it you can’t make the text blurry in Swing.

    Also, it’s easy to add ornaments like a validation red cross over a text field if validation deems the content invalid.

    Simply put they increase the flexibility and plays nice with Look&Feels.

    It should be noted that Painters will never be very good in Swing 1.0 since it wasn’t build with those in mind from the get go.

    Another area they would excel is as Rendereds in Lists, Tables and ComboBoxes. Now a Component is used in Swing, with the tricks and problems associated with that. For instance, in Swing, if you don’t override a couple of methods in the CellRenderer’s returned component to do nothing, your JTables will be slow as heck.


  10. As for me the first task is to create package javax.swing2 and implement all “up-to-date” features of Swing without maintaining compatibility of all that dead code inside. It will make possible faster extension and maintainance of Swing. Of course all great ideas of current Swing should be ported to new Swing.
    Second, one of the most interesting features as for me – Swing is very advanced, it makes customisation simplier for you. And suggestion for throwing exception is not an option – sometimes I am writing special thread-safe components and use them instead of plain components because of all this SwingUtilities.invokeLater(new Runnable() {public void run() {value++;}}); As for me GUI builders should be smarted, so people who are using them really should not care about EDT rule, while if I want smart component – this new politics will always assume I am as lame as all that guys from SQLDeveloper (for example) and will require more work to remake the component to let me violate this rule in my way. There should be better solution, which will be suitable for both advanced and simple guys, or just some startup swing politics or second level of components, like javax.swing2.advanced. And of course, throwing exception from components aboud EDT violation will break any compatibility with old swing.
    And of course binding is third, but it should not be some “few hours implementation” but should use some advanced architecture, to be the best possible solution ever but not a subject of change in every next version.
    As for me generics, enums, varargs and collections are not something that will make your life as swing developer better. Of course with current interpretation of EDT rule ArrayList should be much faster than Vector, but it should be subject for discussion after first parts will be implemented.

  11. javax.swing2 great idea! Standard java distribution needs yet-another gui toolkit to raise the bloatness bar to an ever higher level. I dissagree with the no-new look and feels proposal though. Every new java gui toolkit deserves to have its shiny new ugly look – we shouldn’t break the tradition. In addition I think that properties (and closures) are desperately needed to finish the good job generics did improving the language.

    It would also be beneficial to business. More bloat means more hardware and language changes means more books and training, and api changes means more application rewrites.

    Let the momentum grow!

    1. @Dimitris Menounos: I get the distinct feeling that you disapprove of Swing 2.0. You do realise that the standard java distribution has currently only two GUI toolkits: AWT which is largely unused externally, but which builds the foundation for Swing. So in other words, you’re complaining because Java has one proper GUI toolkit?

      I’m not looking for a religious debate about closures, properties, and whether generics were implemented correctly. I’m far too pragmatic for that. You may be surprised to understand also that just by including a new GUI toolkit there is no requirement for a business to buy new hardware or rewrite their applications in it. Of course, they may want to, but I would suggest a Swing 2.0 application is written from the ground-up as a Swing 2.0 application.

      Please grow up, and return here when you have a positive attitude and something to say. You could have objected to this discussion in a far more adult manner. As it stands you come across as an idiot. I assume you’re better than that.

  12. @Thierry Lefort: I’m a little confused by what you’re trying to say. My argument for Swing 2.0 has nothing to do with JavaFX, and to be fair I wouldn’t want to go anywhere near it as it is irrelevant to the discussion (I believe).

    @Michael: Sounds like Painters should be central to a Swing 2.0 then.

    @Aekold Helbrass: To clarify EDT verification and exception handling, I would suggest that any exceptions be (unchecked) runtime exceptions that clog the log, but not necessarily exit the application.

    I disagree regarding generics, varargs, and enums not being something that will make your life as a Swing developer easier. If that is the case, I suggest you aren’t using Swing enough πŸ™‚

    Also, to clarify, I would assume that Swing 2.0 would start with all of the Swing 1.0 codebase intact, probably building above the Swing-Generics codebase.

    Regardless of whether you agree or disagree with me, thank you for the comments. I am no gatekeeper to Swing 2.0, I am simply trying to spur on discussion so that we can ascertain what is and isn’t priority for a new Swing version. Please don’t take me disagreeing with you as a sign that you are wrong!

  13. I also support an incompatible swing 2.0, there is too much legacy code that makes newbies (and also some more experienced people) cry.

    I would support the idea of allowing svg for icons (and skins if possible), so we can have a single icon for any size

    1. @Chipu: Thanks for the comment. The suggestion regarding SVG icons is a great idea. You must be related to Kirill πŸ˜› Kirill Grouchnikov has done a lot of work in this area, so a Swing 2.0 could potentially incorporate this work to support SVG icon rendering.

  14. Chipu,

    Icon should be a Painter IMO. And for sure, there will be an SvgPainter as well as an ImagePainter. In this regard the Icon interface in Swing 1.0 is pretty good except it API wise seem to have a mandatory rather than an ‘optimal’ size.

  15. I agree with all you said, Mikael (specially with the break of backward compatibility), but I think Thierry Lefort nailed the heart of the problem. The real issue is the API. That API must be designed with use-cases in mind. What do people want to do with a Table, with a List… ?
    What I’d love is to see a very light class hierarchy (like Flash has) and a lot of composition. Remember Amy Fowler’s JNxxx component in the JDNC project ? I think it was a great idea.
    I say let’s wait and see the new JavaFX components. Maybe we will be able to use/wrap/port them to Java.

    Then let’s hope properties will come in Java 8. Until then, the modularity is coming, which may solve our backward compatibility problem.

  16. Let’s not overrun ourselves by trying to make the egg-laying-wool-milk-pig (a German invention – and no, I’m not German).

    With all the changes that people are suggestings, one could very well be starting a project that will never produce anything useful. Just see the amount of time and effort that Kirill has to put into maintaining (basically) one component.

    IMHO we should focus on Swing 2.0, and only that, so no real properties in Java.

    Secondly IMHO it needs to be a rework of the components, but not the engine. So one should extend Swing JComponent but take it from there.

    And there is no reason not to consider putting Swing 2.0 in JavaFX. If there interface between is good (which ATM it isn’t), then that is a valid approach. One may disregard it after consideration, but not before hand.

    Oh, and SVG icons is a good idea πŸ˜‰

  17. About painters… How does that mix-‘n-match with Look and feels? You still want to be able to have a way to buy a skin, so painters should not conflict with skins.

    1. @Dimitris Menounos: Sarcasm does not translate well over the internet if you don’t make it clear with emoticons or equivalent. So yes, you are either an idiot for stating what you did, or an idiot for not making your sarcasm clearer.

      Please feel free to come back to the discussion if you have a proper opinion (I would love to know your thoughts in a clear, more objective manner)!

  18. @Tbee: I agree that we keep it simple to start with. But as with any project, it is best to think twice, code once. What I mean is that whilst there is no code lets talk about what we would love to have in a Swing 2.0. Of course, everyone throwing ideas in is going to result in a scarily long list of things to do, but that’s assuming we are by default doing everything, which of course we aren’t.

    The end result of a discussion is a huge list. Following this we need to prioritise and work out interrelationships between the items on the list. We pick out the ‘easy kills’ and the more difficult tasks.

    I also tend to agree that Swing 2.0 builds on top of Swing 1.0, in the sense that we start by taking all Swing code, and building and refactoring from there. I would love to hear more thought from people regarding this.

    I take your comment regarding JavaFX to hand, but with me being completely lacking in any understanding of JavaFX, it is easier for me to dismiss immediately πŸ˜› Seriously though, if you think there is a possible link, then it has now been recorded in this discussion, so it will be considered more seriously in the coming days should Swing 2.0 go anywhere past this one post.


  19. I am almost agree about codebase for swing2 to be swing1. But It will
    not be good to do big copy-paste of code, it will be hard to find and
    clean all old code that is left for compatibility reasons. May be it
    will be much better at first just to wrap currently existing
    components and then to implement it all step by step, until only some
    core Swing1 parts will left.

    Another question, you said about generics and varargs, but how will it help you? You are right, I am not working with Swing all day long, but I am fan of Swing and I am using it almost all my free time for my opensource projects. And I can feel differenct leaks in Swing, but I can never feel the leak of generics or varargs or enums… And of course i am interested in how are you using it and how can it help you?

    1. @Aekold: Thanks for the comment. I do not know the best way to start with a Swing 2.0. I am certain that Swing contains a lot of useful code, and is sturdy having stood the test of time. I for no reason advocate throwing that away and starting Swing 2.0 from scratch. At the same time, I do not know how best to start a Swing 2.0.

      My inclination is to take Swing 1.0 and slowly refactor it to meet the needs of Swing 2.0. This will require discussion and an understanding of use cases. But it also means that we are trimming the hedges rather than planting the trees, which is far easier, quicker, and more likely to succeed. I would note that the general feedback is to not care about backwards compatibility, which will certainly accelerate the development of Swing 2.0 if it is built atop Swing 1.0. If you disagree please let me know on your preferred approach to a Swing 2.0.

      There are numerous examples in Swing where generics will be beneficial. For example, in comboxes you can ask to getSelectedItem(), etc, and because the component does not support generics, it returns an Object, rather than the type of the object that could be specified in a generic argument.

  20. @Jonathan It’s not about starting simple; all the stuff that could go into Swing 2 is complex enough. It’s about scope; it’s about Swing 2.0, not “properties in Java” or closures.

  21. The starting point must be the API not the swing legacy code. If your keeping the Swing 1.0 API then your stuck with the backward compatibility problems it has.

    If you’re re-thinking the API then you have to start by asking yourself who will be using it and how they will use it. So do you only want the Swing 1.0 developer to use it? Or do you want to broaden your audience?

    Wait a minute … doesn’t it looks like exactly to what Sun is doing with JavaFX?

  22. @Tbee: Absolutely agree about scope, you cleared that up perfectly. You’ll note my initial post said the same thing about it not being about properties or closures. Swing 2.0 is not about healing the Java world, it’s about patching up Swing to be more closely aligned to the needs of desktop Java developers. We need clarity of scope, and hopefully this discussion thread is a step in the right direction.

    Lets keep this discussion going, and see what other people have to say. In a day or two I’ll make another post to clarify the discussion and try to boil down the comments.

  23. > Wait a minute … doesn’t it looks like exactly to what Sun is doing with JavaFX?

    Except JavaFX isn’t Java…

    I’d say start from scratch. It won’t be backwards compatible anyway. At least not in the sense that one can use them interchangeably. On the other hand Swing 2.0 (called SwingIT!) should be very very familiar to current Swing developers. When modularity comes SwingIT can just be used instead of Swing 1.0 for new projects.

  24. @Thierry Lefort: You make good points, and I do not have many of the answers. I hope others can fill in the blanks.

    All I know is that Swing, as it currently stands, is pretty damn good. What it’s missing is a cleaner and more powerful API. I do not want to program in JavaFX, the language does not appeal to me at this point. I also have lots of Swing code that I would love to see being moved to Swing 2.0, to gain the benefit of as many of the features discussed above.

    Therefore, the big question that needs clarifying I believe is how does a project like Swing 2.0 start: Do we build it atop of a potentially broken Swing 1.0, or do we build it from some form of scratch? There are benefits and pitfalls to both sides.

    At the end of the day, I want to be programming Swing. In my opinion, Swing 2.0 should attempt to be as backwards compatible with Swing 1.0 as possible, because the last thing anyone needs is another API to learn..

    That is my opinion, please discuss and disagree. Unfortunately for me I really need to call it a night, so I’m off for now. I will open up the blog so that comments do not need authorisation so that newcomers to the blog can post straight away.


  25. @Mikael Grev: I agree with your statement: Swing 2.0 should be a GUI language familiar to Swing developers. That is my primary endgoal.

    Starting from scratch seems to be the prevailing sense of direction. The question then becomes how can we accelerate the development so that Swing 2.0 is a huge, huge project? Can we make use of what already exists in Swing to accelerate areas that possibly don’t need as much focus?

  26. Current Swing have tons of code. Only looking inside JTable and JTree you have about 10000 lines of code. It looks for me that it is utopia where all this code can be cleaned. There are too much of code left for compatibility and other reasongs, that will be dead for Swing2. While debugging parts like this – sometimes it can take you few hours just to figure out what parts are used and what parts are not. I think that first step – to write some specification for the component. Implement all required methods to declare some component interface, and at first just to wrap existing component. Than all used parts may be copied from existing component. After it will be completed – you will have clean component with no compatibility or dead code. There is always another way – just to look how Qt (being a bit supreme to swing in desktop) moved from 3 to 4 and use their experience. It’s a shame I don’t know how they did it…
    About generics and other… I never thought about casting something is a bad thing in your application, and other things like this. It takes you few seconds, while creating some TableColumnFactory and implementing some AbstractTableModel to be able to add elements, or implementing something similar to code completion, or even just detecting doubleclick… It consumes lots of time, at least in the stage of creating new application. Generics, enums and other is just some piece of API you can learn and use, while customizing your components or making your GUI customisable takes all the time.

  27. Oh there we are … JavaFX is not Java … I knew it was a religious debate not about technology.

    Sun should buy JIDE and license it as LGPL. There you have your Swing 2.0.

    Current JIDE License is not so expensive you should give it a try. After all it is one of the best(if not THE best) Java based GUI toolkit ever.

  28. Man! What a lively discussion! And the US of A isn’t even awake yet.

    Considering that the intention is to break of backwards compatibility on components, IMHO it is not wise to refactor existing code. Swing 1.0 exists and should be untampered.

    So my suggestion on starting Swing 2 (after collecting the features) would be a technical discussion on the basic API and structure of a component (how to do painters, layout, skins, etc).

    Then write the J2Component (extending JComponent), and next a J2Label & J2TextField both extending J2Component and get a serious set of unit test going to drill out the features we wanted.

    After that scrollable stuff (J2TextArea) with unittest, refactoring. And if we got the kinks out of those, then it may be time to consider compound components like tables, lists, etc.

  29. @Thierry Lefort: I would tend to agree, JavaFX (the language) is not Java (the language). It’s easy to prove: I can program Java (the language) but not JavaFX (the language).

    This isn’t a religious debate, it is about accepting that JavaFX has its focus, and Swing has its focus. They may overlap, but they are also different. I write my applications in Swing, because I know Java (the language).

    A company I am involved with did buy a Jide license for me and I have used it extensively. It is a great component suite. It is not Swing 2.0, for the reason you state: it has to be purchased. In addition, it is used in conjunction with a Swing 1.0 application, and it is Swing that is failing the developer, not Jide.


  30. @Tbee: Thanks for the pragmatic advice. It will definitely be interesting to see what the US has to say about it πŸ™‚

    As I mentioned, unfortunately it is late here in New Zealand (getting on to midnight), so I need to head off. I hope you all stick around and keep the discussion going – we need to get a consensus on what a Swing 2.0 means to you.

    Discussion is open (no prior approval needed anymore), so I imagine discussion will continue to be lively for the coming hours.

  31. @bubak: Perhaps you’re correct if you’re a Groovy developer, but for the sake of this discussion, the focus really is on answering the question ‘how can Java (the language) be improved to make developers GUIs easier’? The answer almost certainly revolves around taking a syntax and to a lesser degree an archiecture similar to that of Swing and improving the rough edges.

    In summary, I do not want to learn a completely new API. I want to take my Swing knowledge and be more effective when developing GUIs. I want Java (the language) to work as effectively as it can, which means making use of new language features, etc.

  32. @Thierry Lefort I am totally agree with your points of Swing2, but also I am not a fan of JavaFX. It will be great to make it possible for both Java and JavaFX. It is just some experience with languages without strong types. Don’t declare it is religion vs technology, I can say similar – JavaFX looks for me more politics than Java. Java is suffering from own backward compatibility, but it is suffering of rt.jar but not langspec.

  33. +Model Simplification. Model af swing should be massively simplified.

    Wicket Model is a good exemple of where to go. It is not possible to have a model for each componant. in the end, you have too many class to know.

    (Edited by Jonathan: I assume that ‘=Model simplication’ should have read ‘+Model simplification’. Let me know if I’m wrong and I’ll return it back to how it was).

  34. @Tbee JComponent is not the best way to start. It is better to implement few working components and then move everything they have in common to J2Component, but not start from what they MAY BE WILL USE. As for me specification should be more feature specific at first, like requirements. And then to write strong architecture to solve all requirements.

  35. I couldn’t agree more with a need for Swing 2.0. Just point for discussion – do we really need to stick to the EDT concept? It quite a pain in the ass – you still have to think “am I in EDT or not?”

    I like the way how game engines typically work – they got scene renderer looking for components with “dirty” bit which is automatically setup once some of it’s properties is changed.

    1. @Abraxis: Thanks for the comment! Not that I’m a games expert, but I suspect that they are largely special cases. Multithreaded general purpose programming languages do need to have compromises, and as far as I’m aware, no one has really had any luck making a multithreaded user interface library.

      For that reason, the user interface library has to run on its own thread. Whilst it’s certainly not ‘nice’ in terms of code cleanliness, I don’t thinkwe can really question its necessity. I think the best thing that Swing 2.0 can do is just (and I know you’ll disagree with this) harshly enforce the requirement that all gui-related operations occur on the EDT, and all time-consuming/slow operations occur off the EDT (apart from when the GUI is being updated).

      How harsh is a matter of discussion. I would be happy to see my console littered with runtime exceptions. I personally feel that is the happy mix between having checked exceptions (which just doesn’t feel right in the slightest) to having the EDT checking being optional (which I think will just lead back to what we have now with Swing – ‘slow and broken GUIs’ as a result of developers not knowing EDT rules). Therefore, I believe it should be fixed at runtime exceptions without scope to change this setting.

      That is my opinion anyway, from an oft-confused EDT abuser πŸ™‚

  36. @Abraxis RepaingManager works like this already, you can mark some area of component like dirty, and only dirty area will be repainted. But the problem of EDT is not repainting – repaint() is thread safe already. Problem is every setText(), setIcon(), setAnyOtherStuff() should be invoked in EDT even when repaint is not required, and of course you can’t control like this:
    1 – set other text
    2 – set other icon
    3 – and now it is time to repaint
    because repaint is triggered almost in any component change.
    Somewhere is was told that it is done for component developers should not know how multithreading in Java works… Two questions: 1 – isn’t it good for any Java developer who is working with advanced features like component creation to know what multithreading is and how to handle it, and 2 – all this EDT panic helps you not to think about multithreading for a moment? I am not sure…

  37. Hi everyone!

    What about use the signal\slot behavior as in Qt(

    I’ve used them in C++, they work almost like simple binding.

    Also i think properties are something need!

    The aproach a.value++ is much better than a.setValue(a.getValue()+1).

    But i didnt liked much what ive heard about properties in java7, theimplementation doesnt look good

    public String get name(){


  38. @Jonathan

    Jazz cost money because I invested over 5 years of my time to develop Jazz and I would like some return on investment.

    When Jazz was ready to go public we gave a demo to the Swing team (Hans Muller, Richard Bair) and offered Sun to open source Jazz on SwingLabs but Sun had no interest (not reinvented here…).

    I am are aware that because Jazz is not open source and not for free limits it’s use so we are thinking of open sourcing Jazz as well.

    I am open to suggestions to open source Jazz and make it the defacto standard Swing application framework but I am wondering what’s in there for me? I guess it means the end of my company then…

  39. @Jonathan What you say is right – it is better to throw exceptions, than developers will learn about EDT. But there are some basic methods like setValue() or setText() or setIcon() or other that are better for you to use out of EDT (because of some background threads) and those methods should be implemented in thread-safe manner. It is hard to make whole component thread-safe, but it is not hard to make few data changing methods thread-safe.

  40. @Aekold One could make methods behave two fold: if inside the EDT, well, just do it. If outside the EDT, create a runnable that does the thing and run that with invokeLater.

    The problem in the latter case is that when (for example) the setText method exists, the text is not yet set. That is very unnatural. And if you use “invokeAndWait” instead, you get into all kinds of locking drama’s.

    Been there, done that. I found it to be not a great idea, but it can work.

  41. Im a long time Swing contractor and my main beef with it at the moment is simply that its starting to look a little old hat. The look and feels including Nimbus just don’t cut it in the current market place. When I give demo’s a lot of comments from customers are usually made about how 1990’s things look.

    Now I can play around with gradients within Java2D to improve things some what but its all effort that I think should be simple. Making my own L&F is simply not an option as its so damn hard.

    So I think effort is needed into making the look of Swing flasher. I’d also like to see some of the property binding thats been introduced into FX.

    I suppose what I’d really like is some of the nice new FX features but not the FX scripting which to be honest I don’t like at all.

  42. @Aekold The best approach usually is in the middle.

    My main point is that IMHO one should shake down all the features that are to be implemented with a very limited number of components. And that is something that is quite doable and we could get something working within a limited timeframe.

    I still feel extending JComponent to be wise, in order to preserve Swing 1 and 2 integration; the core engine of Swing should be reused.

  43. @Jonathan: I’m neither game expert nor developer so I just got general idea how it works.

    My point is that for “simple” calls like setText/setIcon (which IMHO are 80% of uses) you should not really care what thread are you in. And if you need to wait till component is repaint with your change, then just have something like setText(“asdf”); waitForRepaint();

    To sum it up – doing this does not break EDT-aware programs (just EDT-related things could almost-ignored) – but it’s practically impossible to rewrite later Swing (1.0 or 2.0 :-)) to support this non-EDT paradigm.

  44. Forget about using enumerations instead of static ints…I did an enhancement request for that and it was explicitly rejected by the Swing team.

    Backwards compatibility is king it seems, fixing broken API is secondary.

  45. > I still feel extending JComponent to be wise

    Then you can’t fix the API. Take JButton. It’s a simple button that extends JComponent. It has over 400 methods!

  46. Yeah, I want to Swing2, too. I’m interested in Swing, although some says its too difficult to learn, But I’m not quite agree with those. JavaFX is cool but I don’t like it. I think its code is quite strange, not as Swing or other tranditional language. I want to learn Swing2.

  47. Regarding multi threading.

    This is generally much harder than many might think.

    Though with real properties you could have ConcurrentProperty instances to handle setting from any thread.

  48. @Mikael True. But you have to keep some kind of integration with Swing. What would you suggest?

    Naturally we only require Swing components to be renderable in Swing2 (just like JavaFX does, hmmm).

  49. Hi,

    I agress will all thoughts.I m biggest Fan of swing.
    Best solution is Framework for swing,the biggest reason for swing failure,bcoz its easy to develop ugly UI easily & EDT mistakes.
    Web development is easy in Java bcoz of 100 web framework,that gives each developer choice to develop apps of his needs.So thier has
    to be framework that take care of bean bindings,EDT mistakes,Animations.. etc that you proposed, their should be not 1,but more framework of choice to make more developers happy.With JavaFx on Sun’s mind,I do not think Sun will help.So others guys like us need some work on this.
    javaFx is good solution,but its still not ready for Enterprise yet.
    Mine biggest prob. with JavaFx is JavaFx code are hard to read & understand in one go.

    Lets hope for best

  50. @Tbee
    I would suggest something in the line of what JavaFX does. Wrapping normal Swing components.

    And, that the Look&Feel classes are made so that Look&Feels are super easy to port. They are reasonably disconnected from Swing so it shouldn’t be much of a problem.

    It is imperative that Swing 2.0 doesn’t depend on 1.0 in any way so that when it takes over the Swing 1.0 module doesn’t have to be loaded at all. This means that we can actually gain startup time and get a smaller download size.

  51. Here are things I’d like to add to Mikael’s posts.

    1. Retained mode API – The desire for advanced effects and painting outside a component space needs a retained mode API to determines when parts of the screen need to be updated. We already have scenegraph so that work is actually already done. We just need a good API to use from java.

    2. Easier creation of models. The Default* models are abused to no end because creating a custom model is considered a ‘black art’. I find direct data binding to be an anti-pattern. There is nothing MVC about it. I’ve written reflection based code to map bean properties to columns so I can just display a list of beans as a table. There should be a more performant/more generic way of doing this.

    3. EDT – Lets look at the alternatives.

    a. Foxtrot ( has a very tempting approach. It allows the synchronous style of programming that currently is considered wrong. If there was going to be a Swing++ then making the changes necessary to support a Foxtrot like system would make scene.

    b. Fully Asynchronous API. Integrate with asynchronous IO to create an event derived io system specifically for swing applications. Seems less likely and requires programmers to always write asycn code. I think Flash does something like this though.

    c. Fast fail. While I hate runtime exceptions it would be a quick way to catch common problems. And to those who think they are smarter then the EDT, you aren’t, and your “safe” component probably isn’t really safe.

    There are no multi-threaded UI toolkits out there. It has been an idea attempted and failed by people a lot smart people. Better single threaded interaction is the way to go.

    4. Better layout managers. along with that a better API for interacting with layout managers. We should not have to embed all the parameters and string ot get the verbosity we need. I proposed adding a varags parameter to addComponent() to help pass lots of constraints. More ideas like this, or some way of using Enums, or annotations or something to give us a readable and maintainable layout system.

    5. A Docking Framework.

    6. JWebPane … hopefully this will be released someday ..

    7. Real MVC design. Swing as it is now is only “model-separated”

    I will post more when I think of them.

  52. Although I agree 100% with the spirit of this post (and most of the comments,) I think there is another aspect that we have not considered. Can Sun afford to work on Swing 2.0? We all know that last week a lot of people were laid off, and some of them from Desktop Java. Sun’s stock has gone down in price big time. Even if Sun has all the good intentions to create Swing 2.0, I doubt it has the resources to do so.

    IMHO, there is more than one aspect in Swing 2.0. First, the technical details (generics, enums, etc.) Second, backwards compatibility (which may be solved with javax.swing2 and Jigsaw.) And third, money.

    I think it would be more likely that Swing 2.0 comes from the community than from Sun. I don’t know if Java’s license would allow this. I don’t know what is really Open Source and what isn’t.

    Does it make sense? Or am I too pessimistic?


  53. I’m all up for simplification, i think a builder/DSL might be interesting in this regard, not necessarily creating new component classes. If the latter was the way to go, not extending JComponent will obviously simplify things, a good thing in the long run i’d say, but a hard goal in order to cover the whole toolkit. (IIRC ken orr has this approach for his mac widgets for java)

    A way to skin, or draw components in a visual tool, for instance SVG support not just for icons, but for lnfs and ui handlers. Painters are good, but i believe it would be nice to support artwork coming from designer over pure java2d code that’d need to be translated from comps. Either that or releasing the nimbus designer tool which generates java2d. I think it would ultimately lead to nicer looking components “easily”.

    I also like properties/binding, but as API, not language changes (while potentially waiting for them in 2012 for java 8): maybe similar to bean-properties or pulpcore’s properties.

    Which of course leads us to animations/transitions which is a must have in my book. So here, either the properties or the swing 2 api would support an easy way to animate things.

    I’d like a way to support different input methods not only a mouse and keyboard, to easily do multitouch, bimanual or multimodal interactions, or games really, even though that’s less interesting for business. Maybe jxinput would be enough, i never really checked.

    In the same vein, I’d also wish the rendering process would be split from the event dispatch if possible, or more generically a way to get 60fps consistently for the next gen & animated UIs.

    I might say while i’m not a fan of javafx script, i really like scenario (the scenegraph underlying the javafx platform): not its API per se, but because it’s a part of how i’d naturally build UIs, so a lot of what i’d like is split between swing 1, the swing 2 features described here, and scenario.

  54. Wow, a lot more posts since I left last night. I think the number one issue that needs a vote right now is the answer to the question how do we get started on a Swing 2.0? The general options appear to include starting from scratch (with wrapping of Swing where applicable), and basing Swing 2.0 on top of Swing with major cleanups to the existing Swing API.

    There will never be a full consensus I’m sure, but it has been (and will continue to be) an interesting discussion. For what it’s worth, I’m not sure which side of the fence I sit on: I expect the simple approach is to rework Swing 1.0, but perhaps the better approach is to start from scratch and try to maintain a Swing-like API.

    @Alex Ruiz: I would be highly surprised that this discussion lead to anything from Sun. I would be more inclined to believe that this be a community effort that may one day be accepted by Sun, but realistically probably not πŸ™‚

    Regardless, we aren’t cutting code yet, we still have a lot of discussion to do. We have to be understanding of the scope of a Swing 2.0 project, and so whilst a number of points raised in comments are great, many just won’t be feasible. We don’t want to be stuck chasing a dream, we want a usable, friendly, clean, powerful, Swing-like API.

  55. Well that brings up the question “What is Swing?”. If Swing is the current code, then well, that has all been released under GLP+CPE so one could fork it and move forward. If it’s an ideology or way of approaching ui development then that’s harder to quantify. I think a lot is possible with a fork.

    1. @Aberrant: I tend to agree – I think everyone agrees that a Swing 2.0 uses Swing 1.0 in some capacity. There is too much good quality code in there to ignore it. Whether components are extended from JComponent or not, there is still a lot of code in Swing that can be reused.

    1. @Ivan: unfortunately I can’t answer that question. But I agree, my interest is in using the Java language rather than what I consider a relatively strange JavaFX language. In addition to this, I would rather use a Swing-like programming approach (with the API being as similar as possible to Swing) rather than a brand new API. So, my vision is simple: Swing, better.

  56. I agree with everything here except the addition of Properties at the language level. Existing property support can survive refactoring – it just requires a bit of IDE smarts. This does work with JSP pages for example.

    There is no good convention for properties at the language level, they can mask performance deficits in code, and they reduce readability. Grab any blop of C# code and tell me what it does without looking at other parts of the code.

    Let’s not make the same mistakes Microsoft made with C#.

    1. @Dan Howard: I tend to agree – properties are not part of my vision for a Swing 2.0. I am quite happy with getters/setters for now. I believe considerable improvements can be had in a Swing derivative without the need for properties.

      Should properties come along externally due to Java 7, 8, n-1 or n, then certainly, a Swing 2.0 should make be upgraded and cleaned up to make use of this. This is the problem with Swing – this did not happen when it had the chance, and the API has become too much.

  57. There are lots of things I would like to improve in Swing, and Swing 2.0 (with a clean API) may be a good way to go about it.

    I would also love to throw away the existing code implemented with Swing, but this is not an option after many person years of work. We would need a way to implement new functionality with Swing 2.0 while allowing existing functionality to continue running. We would therefore need a way to embed Swing 2.0 in our existing Swing application. (This is something JavaFX has so far failed to deliver.)

    One method of doing this is to maintain backward compatibility, but I think this comes with a large cost. Another way is to build an adapter that allows Swing 2.0 components to run inside Swing containers.

    There should also be the ability to embed Swing/AWT/JavaFX/SWT components in Swing 2.0 for maximum flexibility.

    1. @Larry Singer: I agree – I think some form of wrapping is important to allow some form of reuse.

      Unfortunately, from the discussions I’ve had with people regarding Swing 2.0, the real issue is that with such a (currently) hugely scoped project, it would be difficult to develop a solution that can make it all the way through to being truly usable without some form of funding. I am trying to have some discussions around this, but I’m just a guy in New Zealand – it’s really up to everyone out there reading this to push for a Swing 2.0.

  58. +1

    I’m only not sure about collections. Vectors should go, but should it be replaced by List etc. in API? I will be happy if we could use only proper interfaces as Model not collections. Maybe default implementation should accept new collections, but something like new JList(List list) should not be allowed in my opinion.

    JavaFX is not Swing 2.0 but I believe this was marketing decision not technical one. When I was reading about F3 it was very much said what it will be better way to build swing application. Sun just changed mind in one point, maybe they should again.

  59. swing 2 must be a modern api, tailored for the future : shouldn’t swing be based on a GL binding (JOGL or LWGL) to be able to have 3D effects ?

    1. @Aekold: That is possible I guess, but I think at the moment we need to just keep discussing what a Swing 2 means to people. I’m about to start up a forum so that discussions can be a bit easier. I’ll make a new post once I do.

  60. “I’m not a JavaFX person yet, simply because my day job is fully Swing, and it will be for the foreseeable future. For this reason, Swing 2.0 is what I need, not JavaFX.”

    That is basically a non-reason. You don’t want it because your employer doesn’t want it for some unnamed reason…

    JavaFX isn’t perfect and it’s possible that a revised Swing could potentially be a better fit for certain applications.

    However JavaFX really has a lot of advantages, it’s a very serious contender for building rich-client desktop apps or plugin-based web apps, and when proposing a new version of Swing, you really need to adress it at a little more depth than “just because”.

    1. @Mass: Thanks for your comment – I’m open to people disagreeing with me πŸ™‚

      To clarify: when I say my day job is fully Swing, that is because I am a full time developer who chooses to program in Swing. I am CTO of a software company, and so I choose Swing based on the fact it has been available for the life of my software, that the people who develop the software are skilled in it, and that Swing has never let the software down. Also, any outside work that I do I inherently choose Swing, because I know it so well and it works. Therefore, your second paragraph is moot – I don’t choose Swing “just because”, I choose it because it works, is powerful, and I have invested a lot of time to know it well. Throwing that away to instead use JavaFX just doesn’t make sense to me.

      The feeling from the feedback I am hearing is that many people are in the same boat – they really like Swing, and to some degree don’t want to lose that when moving over to JavaFX. They feel like moving to JavaFX means that they have to throw the baby out with the bath water, and it doesn’t compute πŸ™‚ At the end of the day, I want a cleaner Swing-like API, not a completely new one. That is my reason for a Swing 2.0 and not using JavaFX.

  61. My daytime job is 80% swing. But I’m in doubt between JavaFX and Swing. User interfaces have become more fancy and Swing is not the best platform to add that too.

    I’ve build an a.o. “apple menu” in Swing myself and know it is not the most practical frame to do animation in and the animations are not extremely smooth. So JavaFX certainly has merits when it comes to fancy GUIs.

    I also have done some flash, so I converted a screen I wrote to JavaFX and was very pleased with the code-first approach. So JavaFX has some plusses on Flash.

    But for normal administrative forms the JFX animation is overkill. So JavaFX as Swing replacement stands-or-falls with how well they will be supporting Swing alike coding. As it stands now, it is not sufficient.

    However, the problem of learning a new syntax is not what is holding me back from JavaFX; it simply is not a replacement yet. But the syntax would never be a reason not to switch. We in the software business continuously have to learn new things. It took me quite some time to get the feel for JGoodies binding, more than the JFX syntax. As soon as you are at the point of “I’m comfy here, I don’t want anything new”, then you’re on the dangerous side of the hill IMHO.

    So ATM JavaFX is not a replacement for Swing. 1.1 or 2.0 maybe, but who knows. And when will it arrive? Swing 1.0 always has me working around shortcomings because of its legacy. So if people are willing to rethink the basic Swing framework and write new components, I’m in and contribute some myself.

    But I would very very much advise anyone to take one day and at least try JavaFX. It is not wise to form an opinion without having tried it.

  62. @Tbee: Absolutely. I tend to think Swing is the right API for programming enterprise software, which is where my mindset is. I like nice-looking swing applications, but I’m not looking for inconsistent, animated, ‘designed’ user interfaces as much as I want a nice, enterprise look, with a cleaner API underneath to make development easier and less error prone.

    As a side note, Thierry Lefort has taken the opposite point of view to the one taken on this blog, and you can see this here:


  63. Showering always is a good way to gather one’s thoughts.

    Do we really want to invest our time and effort into a framework that is compatible with Swing (just like JavaFX), has a better painting logic (just like JavaFX), supports binding out of the box (just like JavaFX), and preferably does make properties and actions/events easier (just like JavaFX)… but is -in fact- competing with JavaFX to become the new Java GUI toolkit?

    My beef with Swing, and the point that I was trying to push (hard πŸ˜‰ ), is that the core is ok, but all the components need to be rethought and rewritten with user friendlyness in mind. So I wanted a new clean shiny J2Component and start from there. I’m leaning towards JavaFX CustomNode to be that new component…

  64. If you want to know what needs fixed most in Swing, you need to survey the other Java GUI Toolkits. Buoy has a good analysis of Swing’s problems.

    The hard question that isn’t being addressed is who will do the coding. I would love to see a Swing 2.0 that ditches JComponent. Without doing that, you won’t be able to address most of the basic flaws.

    With limited resources, however, I think a much more reasonable strategy is to identify existing projects based on Swing (Spin, SwingX, GlazedLists, EventBus, BeanProperties, etc…) and consolidate them into a tested, documented, and supported whole.

    Actually, just a well organized catalog of existing Swing extensions would be useful. Add descriptions, comparisons, and other useful meta data and it would be even better.

  65. @Curt Cox: I agree – there is a huge amount of support I feel for a Swing 2 that cleans up Swing, but everyone is busy with their own projects to be able to focus on it. As I mentioned earlier, and as others have mentioned to me, it is a project that really needs a few talented API designers who know Swing well to sit down and plan the improvements.

    I agree regarding pulling together lots of other projects, but the end result will still be based on the current Swing API. Making a list of their functionality and availability would be a nice first step however.

    1. Just a quick update, Danny Coward has a blog at Sun called The Planetarium. He has posted a quick blog post acknowledging this discussion here. Danny Coward is a big name within Sun when it comes to JavaSE.

  66. I use Swing and really like it. I don’t think its all that tough to learn though there are some things that could be easier. Alot of the items that are being mentioned sound great, but I do really think that we do need more components and themes/skins/LnFs built in. Sun should live up to its commitment to and leverage the great work by folks like Kiril and Romain and many many others and throws its weight (programmers, resources, etc) to get their stuff into Swing 2.0. It should also look look at and glean the various Ajax toolkits out there and understand that if it really wants Swing to be the UI toolkit of choice, it really does have to compete against all the ‘pretty’ stuff out there. But that’s just my 2.0 cents.

  67. Hi

    Some quick thoughts:
    1- I suggest everyone take a look at: Thinlet, Pivot, Buoy, Foxtrot, Glazed Lists, et. al. to see what alternate takes on lightweight Java GUI frameworks, or solutions to Swing dev problems, are already available. Pivot in particular is a complete GUI toolkit which was started recently and is in active development. Buoy has some great ideas. You might just join one of those efforts.

    2- As far as coding goes, you could save a lot of time by starting with an existing Swing codebase. There are three complete or mostly complete ones I know of as part of OpenJDK, GNU Classpath, and Apache Harmony. Just pull out the javax.swing.* packages, open in your editor, rename the top-level packages, and start hacking. If you keep a couple of Swing projects open in your IDE at the same time you could even refactor both Swing and the apps at the same time. Just choose a license you can live with.

    3- I would try and contact long-time Swing developers (there are some like Jeanette on SwingX who started with Swing when it was in beta) and take an interest in their input and insight.

    4- I think a good community goal is to make sure it’s fun to use. Take a look at the enthusiasm around, say, Processing and Groovy’s SwingBuilder. It’s a practical idea to support the business market, but if you can get hackers and hobbyists interested in playing with the APIs you’ll get free press, feedback, input, etc. Those folks will let you know with no hesitation when your APIs are getting complex, hard-to-use, etc. And when you hit a home run, they’ll be there to cheer you on.

    Thanks for starting this discussion.

    1. @Patrick Wright: Thanks for your thoughtful comment. I am definitely trying to contact people who might be interested. If you know of anyone, please email them directly and refer them to this blog.


  68. Hi all,
    For me Swing is part of my daily job and I learned to love it and to hate it. I believe having an Swing 2.0 would be a wonderful thing.
    There are a lot of interesting ideas here. Mikael Grev has already highlighted most of the severe problems with the current Swing implementation.
    We develop now for 10 years a big Java application. It has 30000 classes and 4 million lines of code.
    We started with Java 1.0 some decades ago. We kept it up do date all the time and currently it is migrated to Java 1.6 it uses Generics in all ways and makes good use of all modern Java APIs.

    How did we manage it to keep the application alive for this long.
    Refactoring! Even BIG refactoring.
    So my advise is. Take Swing 1.0 and start refactoring. Even complete radical changes are possible with refactoring when done right. To change some APIs or to get rid of old components some times took 2 years and longer but someday you are finished.

    Why not write from scratch? It is alluring. But is there only one guy around that can claim that he will do everything right straight from the beginning. Well start from scratch and plan a big Swing2.0 and in 5 years from now you will perhaps be finished and have a Swing 2.0 that will be better in some areas and some others will have problems as bad as the problems that you have now with Swing 1.0
    So copy the current swing and start refactoring. Add methods and models with generics and make the old ones deprecated. Find all references to the deprecated methods and remove them one by one and you will have a Swing 1.0.1 Add Painter Support to all components and you will have an Swing 1.0.2, …

    Just my insignificant opintion.

    – Bernd

  69. @Bernd Rosstauscher: Your opinion is just as significant as everyone elses! Your thoughts are much appreciated, and I tend to agree that refactoring would be much easier, in the sense that people will instantly see progress, and we can follow a more ‘release early, release often’ approach.

    Personally, I love refactoring, especially major refactoring – it’s like breaking apart a puzzle and trying to put it back together again, but with the challenge of making the code better, cleaner, and less complicated/bloated.

    I’m all for either Swing 2 approach, but my inclination is often shifting. Right now I agree that a refactor is better and faster than a rewrite.

    Keep up the comments, now moreso especially because we are slowly getting the attention of people within Sun.

  70. As a every day entreprise programmer i’ve take a look at JavaFX. My question to sun is : how to i deal with my legacy code ? how can i build entreprise level application without even basic standart component like Swing ?

    FX respond to a need of multimedia for the multimedia client application it could not be a replacement for Swing until several months and only if it lead to an advanced framework which noboby now can even imagine.

    The idea i got from Swing2 is a SwingX visually reach components framework based on the last Java grammar evolution. And said like this it perfectly feel the gap for every day job.

    I do REALLY HOPE that some strong DECISION to START SWING2 will emerge from this thread.

    Cheers !

  71. Well, I don’t know much but I am busy learning JavaFX and I am learning about Swing indirectly so I can use it in JavaFX.

    I suggest you figure out how to use JavaFX in Swing and you will make a lot of friends:-)

  72. Pingback: Anonymous
  73. Starting from scratch seems too daunting and not many understand the internal of Swing well enough to make radical architectural change (though with the Swing team’s help, it is possible but now their focus seems to be JavaFX).

    Just like Aberrant thought, Is it to possible to fork out the existing Swing and probably start from there like remove deprecated methods, standardised call, add additional classes, update it (like use ArrayList and generics in gui datamodel), improve it (adding MIGLayout as core, etc). Over the years I have improved certain classes in Swing that hopefully can be backported in “new Swing”. It is very likely to break binary compatibility.

    Improving the Swing to such extent in OpenJDK seems impossible since Sun still wedge control over it ?

  74. I love the idea of a swing2.0 that is separate from JavaFX. I’m a groovy guy myself, but I still see a need for a swing2.0.

    I would love to see it built on glazedlists, my all time favorite java library.

    I also agree that taking swing1.0 and going for the swing2.0 goals via refactoring is probably the best way to achieve anything.

    My vote would be not to wait for properties in the java language.

    I love all of Mr, Grev’s ideas except waiting on properties.

    If we have to have properties, I’d rather have something we don’t have to wait for in the language, but use something someone was pushing on a while ago where you don’t use String or Integer, but StringProperty and IntegerProperty and they have built in events and such. I know that’s likely to be controversial, though. But if we had that, we wouldn’t have to wait for properties in java.

    it’s just that properties in java is such a great idea, but for some reason hasn’t made it so far, so I don’t see it making it at all.

    I also like a lot of the ideas in JMatter, though I don’t know that they are applicable in swing2.0.

    I also agree that manpower is a big issue. I don’t feel that I am all that much of an expert to be able to do much of the intricate coding, and it’s hard to find the time.

    So, big thumbs up to Mr. Grev and swing2.0.

  75. Regarding properties – I think Swing 2.0 can NOT be dependent on them – even if they are available in Java 7, still there are many good reasons to keep support for Java 5 (or at least 6).

  76. +1 from me. It seems that by posting this, and by the response, you are now have the ball to organize this… πŸ˜‰

    There is one point that I would be willing to work on: models. Most of them can be easily generified without really impacting that much on the rest of the API. For example, a ListModel can become a ListModel. Then we can have a series of model implementations that constructs models from collections. For example: ListModel CollectionsModel.createListModel(List list).

    I am already forced to do things like these… and other people here have already complained about models too…

  77. I generally like most of the ideas presented so far, but I disagree with some of Mikael’s suggestions.

    * I think Components should NOT be able to paint outside their bounds (drop shadows should be handled differently if you want them to extend beyond the component bounds. Just have a way for components to paint on another layer, where their bounds don’t apply.

    * I think Components SHOULD be containers – e.g.: the idea that an editable combobox contains a text field and a button makes sense.

    I think properties are needed if you are going to put in the effort to make a Swing 2 that is the time to get properties into the language.. rather than having another mismatch when they are added later. (Just like we have with collections framework and swing now. Or static final ints and no enums, etc.)

  78. I would suggest that there are too many layout managers in Java SE. For the average user this causes a great deal of confusion.

    A new layout paradigm that allows the users to put components in limited number of ‘structured’ containers such columns, rows, grids, tabs and cards with proper specified alignments will simplify the Swing programming considerably. Imagine being able to do something like this

    createRow(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)

    createGrid(verticalAlignment, horizontalAlignment, twoDGUIObjectArray)

    createColumn(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)

    where the arrays contain Swing Components or the aforementioned ‘structured’ containers.

    This will be an order of magnitude improvement over the existing way of doing things, and make the concept of layout manager essentially irrelevant for the typical users, obviating the need for every tom, dick or harry to invent his own layout manager and proclaim it to be the best among the lot.

    Of course such an approach has already been implemented, but Swing can do it too.

  79. @Tom Corbin
    Bean Properties might be the project you are thinking of.

    I actually prefer the approach of using a well defined property interface to that of adding properties to the language. There are a few similar projects, but I think that one is the most developed.

    The problem with using an enhanced definition of properties and beans is that tool support will lag. Nonetheless, it is worth doing. Jettisoning the inherited AWT methods have similar consequences that are even more drastic. The current level of AWT interoperability that Swing provides has long since ceased to be worth the API price it imposes.

  80. +1googol for Swing 2.0.

    Let me add my own todo list :
    – pure Java2D default PLAF
    – full support of alpha chanel (yes, I want to be able to do overlay in applet over a HTML page)
    – default vector base plaf (nimbus)
    – enhanced java control pannel (default LnF, properties configuration, etc)
    – Editable list (“yes we can”)
    – default Bean friendly/aware model
    – tight integration with EJB : automagical link established whatever is the network condition (proxy, etc) security)
    – default renderer for esasy SVG integration (design a SVG resource with two ID and $text and use if as button) : key feature to bring design
    – enhanced HCIL event support (multitouch & all) : I am already on this one πŸ˜‰
    – full CSS support for styling using class and ID=command
    – more default component for usual things : DateSelector where art thou πŸ˜‰
    – scene model
    – animation engine

    On the last points, I think lot can be “borrowed” to JavaFX …

  81. If we’re starting from a clean sheet of paper, I’d want to see the class hierarchy flattened — no deep inheritance chains. It should be vastly more compositional (interface-based). Why should I have to inherit hundreds of methods in order to have a menu? (JMenu has 433 methods at last count.)

    Don’t force me to subclass already-huge classes, or write wrapper classes, in order to do simple things. Give me some lighter weight alternatives to the big kludgy JMonsters. I don’t need all 433 methods of JMenu and its ancestors.

    If you’re writing JavaScript, there is no way to subclass a JComponent and override a method in it (from a script), so those of us who use Rhino (or the embedded scripting features in Java 6) “in anger” are left no alternative but to … feel angry.

    It might be good to have Swing Lite and a Swing Heavy that wraps the Lite (?) — but I still favor more compositionality and less inheritance as a motif for

    Thanks! Great post. Great dialog.

  82. Swing is great but there is a lot of work required even to do simple things. Rather than start with all the complicated cases how about starting with simple things that people do in every application:

    * display dates (without using an external library)
    * display currency
    * display images (much more simply than now)
    * tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc). Then the default model could be used in most cases.

    People avoid Swing not because it doesn’t have enough power. They avoid it because it is too much work to do basic things (display an image requires understanding how painting works, instead it should be a single call on a component to place the image).

    The problem with Swing is it was designed by very clever people in a hurry, which makes it slow for less clever people (think government or corporate developers) to develop things in a hurry. This is the real Achilles Heel of Swing as it is.

    Swing 2.0 needs to be “As simple as possible, but no simpler”.

    1. @Mike Reid: Thanks for your comments. I think the problem with any API is that you need to know all of it to be a power user. Swing perhaps complicates this by having a huge API (due to inheritance). In the case of displaying images, you can always put them into a JLabel.

    2. To everyone commenting, thank you. Your support for the project, or your comments against the project, are all welcome and appreciated. We have succeeded in catching the attention of Sun – they should be getting a response back to us within the next day or two. I will post a new blog post then, and will post a comment into this post here so that anyone subscribing to comments is updated.

      How Swing 2.0 continues next is a function of how Sun responds to our suggestion, so we must now wait until we hear from them. Despite this, please continue adding your suggestions to this blog post – it is certainly the best place to gather your thoughts on Swing 2.0 at this point in time!


  83. @Gabriele Carcassi: I am trying my best to organise a Swing 2.0 :-). The only reason I have gone quiet is because I’m waiting to hear back from Sun. I would dearly love to get their feedback, and based on their comments so far, they may generally accept some, but not all, of the Swing 2.0 points in this blog. This is reasonable as this post has contradictory requests. I purposefully kept my initial post shortened to what I consider the minimum requirements for a Swing 2.0.

    Perhaps instead of Sun accepting a need for Swing 2.0, they will possibly support a ‘Swing 1.5’ (Thanks to RΓ©my Rakic for that term) – in other words a more basic upgrade of Swing to support Java 1.5 features. This could be a good start.

    Anyway, enough crystal ball gazing – I will update when I hear more.

  84. @Johnathan Kia Ora
    “I think the problem with any API is that you need to know all of it to be a power user.”

    That’s not so bad. The problem is not with us power users, I believe is the fact that you have to know quite a lot of Swing’s implementation details (EDT etc) to be able to do anything other than the simplest things.

    Again, there’s no default way to display things such as dates or currency that appear in a large proportion of applications. It is not that it is difficult to do, it is the fact that you have to do any work at all for these simple things that is a design flaw in the default set of Swing components. Building CRUD applications (that can display common SQL-derived data) is far, far more work than it needs or ought to be.

    Fingers crossed Swing 2.0 makes a difference. Thanks for giving us a forum to air our ideas.

  85. @Mike Reid: ah, looking at your email I see we have another Kiwi on the site πŸ™‚ You may or may not recognise the images in the title banner on this site as Waiheke Island. Anywho, I digress.

    You make good points. I push for a Swing 2.0 that enforces total EDT compliance. Like I said in my initial post, it will make developers unhappy until they learn the rules, but it makes the end result far better. It is worth it.

    Additionally, there may be scope to improve the means of interacting with the EDT, but that is a discussion for another day.

  86. I would like the following in Swing 2.0….

    …I would like to replace AWT with SWT.

    …I would like an interface-based UI that uses a factory to create instances such that applications can plug into the factory to customize components. This enables me to use Swing API to develop most any kind of GUI, the specific implementation of UI toolkit can be customized by application.

    …Removal of ‘renderers’ from API. Renderers prevent using Swing to develop thin-client UIs since the renderer concept does not translate well to client/server architecture.

  87. @ted stockwell

    There is already an implementation of Swing on SWT, called SwingWT

    Incidentally, SWT works best on Windows and less well on other platforms (IMHO). It certainly has a lot of subtle inconsistencies between platforms (at least for the products I’ve built with SWT). In addition, SWT’s internal implementation ‘style’ seems quite Windows-like and old-fashioned (eg. variable namimg) compared with the Swings – but as I said, this is just a style thing.

  88. Just wanted to share some specific examples of how we have addressed a number of these issues with Pivot:

    * “Generics-based, support for enumerations where obvious” – Pivot requires Java 5 as a minimum, which allows us to take advantage of newer Java language features throughout the API.

    * “Improved support for bean binding and validation” – Pivot’s built-in data binding framework makes it very easy to bind bean classes to form elements.

    * “Better handling of the validate/invalidate/revalidate/repaint mess. You should never have to call these as a developer.” – Unless you are developing custom components, you will generally not even need to be aware of these methods as a Pivot developer.

    * “Layered painting build in from the start.” – Pivot’s decorators serve exactly this purpose. See

    * “Components should be able to paint outside its bounds.” – Decorators are also used for this.

    * “min/preferred/max sizes should be width/height and not size.” – Pivot includes support for both constrained (i.e. width that varies by height or height that varies by width) and unconstrained preferred sizes (like Swing’s current preferred size).

    * “All Components shouldn’t be Containers.” – Only components that actually make sense as containers are implemented as such in Pivot.

    * “Better thought out listeners.” – We think we’ve done a pretty good job partitioning events into meaningful listener interfaces in Pivot.

    * “A single Window ancestor that is actually used in the API” – Pivot’s Window class acts both as an undecorated window as well as the base class for other window classes such as Frame, Dialog, Popup, etc.

    * “Adhere to the transparency of Colors. No isOpaque()/setOpaque(boolean) debacle.” – Supported.

    * “Oh, and SVG icons is a good idea” – Vector images aren’t fully supported yet, but the API was designed for this. Both bitmap and vector images share a common base class so they can be used interchangeably.

    * “Retained mode API – The desire for advanced effects and painting outside a component space needs a retained mode API to determines when parts of the screen need to be updated” – Decorators accomplish much of this.

    * “Easier creation of models.” – The same model interfaces are used by all data-driven components (lists, tables, and trees), and there are far fewer of them. We think this makes them much easier to work with.

    * “Better layout managers. along with that a better API for interacting with layout managers.” – Pivot containers and layout managers are not implemented as separate concepts – they are integrated. In our opinion, this approach is easier to work with, and is also the approach taken by Flex and Silverlight.

    * “Real MVC design. Swing as it is now is only ‘model-separated'” – Pivot components are defined by a model, a component, which acts as the controller, and a skin, which serves as the view.

    * “pure Java2D default PLAF” – Pivot ships with a default cross-platform look and feel called “Terra”.

    * “more default component for usual things : DateSelector where art thou” – Pivot 1.1 includes a standalone calendar component as well as a drop-down calendar.

    * “tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc).” – Supported. Pivot includes a cell renderer class called TableViewMultiCellRenderer that automatically renders cell content based on its type.

    Throughout Pivot’s development, we often talked about it as “Swing 2.0” – I’d suggest that anyone interested in the topic of “Swing 2.0” at least give it a look.

    Again, there’s more information on the project site and in the Apache proposal:

  89. Yes we need Swing 2.0, but I would say we should go further and try to consolidate everything we’ve learned since Swing 1.0 while we’re at it.

    1) Widgets should address use-cases out-of-the-box without customization.

    2) All forms of customization should be *heavily* documented and made as simple as possible. In my experience, Swing can do anything but no one knows how to implement it nor is it trivial to do so. I strongly believe we can do a better job the second time around.

    3) One piece of advise: don’t freeze the API too early. I would advise freezing API components only if they haven’t changed for over 2-3 years. That should be enough time for the community to catch any design flaws.

  90. swing 2.0 :

    Painter,Timing Framework++(Project Scene Graph),JSR295,JSR296(need more simple),Powerful-LayoutManager(MigLayout,JGoodies-FormLayout…etc)

    does anyone have other idea?

  91. re painters: While I think the idea of painters is awesome (being able to replace specific parts of the painting code with your own implementation without going through the LnF hacking stage would be great) I do think that the current incarnation of them (in SwingX at least) could do with some work. For example a painter has no intrinsic size, this leads to separation of logic (in the bad way), for example in a TextPainter that is used to paint a label how does the label know what size the text is going to be so that it can decide on it’s preferred size.

    On a related note one of the features that I would quite like to see re-thought in swing is the minimum/maximum size properties. These APIs, while having the best of intentions, could be accomplished using a single API that also provides much more flexibility for a component to define how it should be re-sized.

    For example I’ve been experimenting with something similar and found that an API like public Dimension fitInto(int width, int height) allows for much more flexibility (for example you can define a component that maintains it’s aspect ratio, or only stretches in the vertical axis or has a maximum width or any combination) with a single api method. A similar API for painters (and scalable icons where I currently use it) could also be used.

  92. Miglayout? Ha!

    All we need is to start requiring Java programmers to instantiate objects with arguments like this: “[10][20:30:40][40!][::40]” (typical argument gleaned from the Miglayout guide in a few seconds).

  93. +1 to better EDT enforcement.
    +1 (and then some) to support for generics, and ditching Vector in every dang constructor.

    -400 to the suggestion to remove renderers. . . DO NOT DO THIS!!! The capability to completely customize the appearance of complex components such as tables is one of the major reasons I currently choose to do GUI development in Swing; reducing the power of the toolkit isn’t the way to improve it.

    Don’t think language-level properties should be required; the .NET implementation, at least, tends to make it extremely hard to determine what will and won’t automagically update; I’d rather have to explicitly call a method (or something) so that I know I’m updating a property and triggering changes elsewhere.

    Having a good TreeTable or other multi-column tree implementation built into the toolkit would be really, really nice.

  94. @gregor: You’re welcome to continue using current layout managers. I in fact have never used MigLayout (sorry Mikael!) – but I have used a similar framework heavily (JGoodies Forms). The question as to handling layout managers is a complex one – I understand their use, but I don’t know of a better way to handle laying out components if layout managers were to be wiped out of Swing tomorrow. Thoughts?

  95. @gregor

    A bit short sighted, maybe peek a few more seconds. I usually use one of the other syntaxes that MigLayout supports;

    add(xxx, new CC().spanX(2).fillX())

  96. Regarding EDT (again) – just an idea for brainstorming: Is there any reason why NOT to wrap every “setter” (.setText, .add – etc.) by something like this?

    if (!isEDT()) {

    Then Swing2 API would be “non-EDT” and inside we could keep using EDT or anything else in future.

  97. @tbee

    add(xxx, new CC().spanX(2).fillX())

    is not much of a improvement over


    Look, I don’t want to bang on one Layout Manager or the other. The point is that if so many Layout Managers have been developed because those bundled with JDK suck, and even the new ones suffer from the need for such cryptic commands, perhaps some new thinking is required.

    I think Java Sun people basically know this. As late as 1.5 they had to come up with a new Layout Manager, and they gave us the Group Layout Manager. The earlier versions of JFX had used Group Layout, but finally as far as I understand they have given up on it.

    Imagine that JDK required you to specify your own hash functions for different type of objects, and the JDK came with a sucky hash functions that work only with Integers and Doubles.

    The situation is similar with the concept of Layout Managers. They may be necessary evils, but a higher level abstraction is needed for the programmers who just want to show a nice looking table of components for example.

    1. @Abraxis: Alex is correct – you have to remember each time you put something onto the EDT you are creating a new Runnable, so performance would be killed by do each setter individually. It’s a nice idea, I have done similar in the past, but not at the level of setters – rather when I know a method should be called on the EDT but it may not – but I bunched together all EDT-relevant operations into that method so as to not kill performance.

  98. I stumbled upon this discussion per chance. I think it’s an excellent idea and I agree with the majority of what’s been said. A cleaner simpler API would solve a lot of problems when developing gui applications in Java.

    I am a bit surprised that very little has been mentioned about unit testing though. I’d personally like to see a framework or an ability to unit test my gui code. I’m currently using FEST which has become an indispensable tool to me. It however has a lot of shortcomings, most notably that the swing components are actually visible and the mouse cursor is controlled by the unit tests while they run. This leads to slow tests and also renders the computer unusable while the tests run.

    Wicket is an excellent example of where a good simple (to use anyway) unit test framework improves the developers life in testing. A web server is not required to be running like so many other web frameworks.

    In a similar approach I’d like to see some sort of test container that mimics the OS gui and the unit test in effect does not need visible components or the user of the physical mouse cursor.

    That’s my 2 cents worth anyway. Nothing quite like dumping ideas on others that haven’t been thought through thoroughly.

  99. @Jemsquash,

    I’m pleased to hear that FEST has become an indispensable tool to you. I’m also interested in known the shortcomings you have found (besides the mouse-controlling behavior.) Would it be possible to talk about this in private or in the FEST mailing list? I’m always looking for ways to improve the project. Thanks πŸ™‚


    I apologize for talking about FEST stuff, not related to your post πŸ˜€


    1. @Alex Ruiz: No problem – I’m glad testing has come up, as it was always something I imagined should be researched leading into a Swing 2.0, and if desirable, be made part of the scope. I’m sure an API designed with testing in mind would be nice for some developer. For that reason, it is great to have you monitoring this discussion Alex πŸ™‚

  100. @Jemsquash

    I did that in my application a few years back, as the solution to the EDT problem, even considered using AspectJ to do that for everything javax.swing.

    However I ran into unexpected behavior, can’t remember what exactly. Then I switched to using invoke later, again unexpected behavior (setText had not set the text – yet). Did manager to fix that with a second variable holding the value, but ended up installing the EDT checker and really resolving the issue.

    All this may very well have happened because of other faults in my code, so the solution may work. As said; AspectJ can solve a boat load at once.

  101. @Jonathan: yes, there would be some overhead but my point is that this overhead mostly already exists! Lot (most?) of Swing developers is already using “invoke*” or have to bypass it somehow (send “messages” to EDT).

    So why not just make our daily development easier? And if creating new Runnable shows to be the bottleneck (which I don’t think so – just a feeling, no hard data!) then we can change Swing 2.0 internals to be more effective – while still keeeping API!

  102. @Abraxis,

    I tried something similar to what you suggested (EDT access in setters) and performance was horrible. Once we consolidated many actions in a single call (or Runnable) in the EDT, performance was not only great, it was faster than not using the EDT at all.

    My point is that using Runnables in the EDT do not imply performance penalties if we use them *correctly*.


  103. @Abraxis,

    I re-read your last comment. If the overhead you talked about is the overhead for the developer to deal with a cumbersome API, yes! I agree with you. Simplifying EDT access (API-wise) is a tough problem to solve, IMHO, and without closures in the Java language even tougher (my intention is not to discuss if Java should have closures or not.)


  104. @Alex Ruiz: EXACTLY – “using Runnables… correctly”. Let’s face it – there are many developers who just does not care about anything else then if the code compiles and does +- what it should πŸ™‚

    Can’t we somehow make Swing more intelligent so you don’t have to think about EDT? Just an idea without too many deep thinking – if bundling more changes into one EDT call dramatically improves performance, then why not let Swing to have “change queue”, put required changes in this queue and once a while (100ms) process whole queue? (of course it’s very rough idea, implementation would have to very different ;-))

    Again – my main point is to allow developers to call label.setText(“Hello”) from any thread.

  105. @CurtCox

    That was exactly what I was thinking about, only half remembering.

    It’s a very interesting project, though I doubt any one else would use it. It looks very powerful, though.

    I’m betting sun won’t help – I don’t think they have the manpower or interest. In fact, I’m guessing they’ll want to discourage this work by making it hard to keep up with swing1.0 improvements.

    But I guess we can only wait and see.

    My preferred way of handling Swing 2.0 is to start with Swing 1.0 and start doing refactoring. I think we’ll get the most bang for the buck and while we wouldn’t be 100% backwards compatible, we’d maintain the most backwards compatibility this way and lower the learning curve.

    I do have to admit that Pivot (and others) sound great, I’d rather incorporate their ideas into a swing 1.0 refactoring.

    1. Just an update: Danny has posted his thoughts on Swing 2.0 on his blog here:

      It’s pretty much as expected – they need to be conservative so an incompatible Swing 2.0 is not something they can do. They do encourage other people to do a Swing 2.0 externally however, given that all source code is available.

      What are your thoughts?

  106. I haven’t read all this thread yet but I just thought of something that might make this thread keep going MUCH longer. πŸ™‚

    For swing2 why not drop the layout managers and follow the MS way of using containers with relative layout.

    I would love that – I could never get my head around layout managers.

  107. Not to be an ass, but this conversation sounds more and more like it’s being run by a bunch of amateurs. A few of the suggestions that have been made make little sense yet no one called them on it. I also get the feeling that there isn’t a single senior API designer here.

    Yes, we need Swing 2.0, but there is little sense working on it without some very senior developers leading this effort. Good luck nonetheless!

  108. @Gili: As I’ve said all along, this thread is meant to facilitate discussion. Discussion isn’t facilitated when you’re pointing out peoples errors – it makes people shrink back inside themselves and become afraid to contribute. That is a basic rule of any brainstorming session.

    The next step of a Swing 2.0 discussion would be to be critical on all ideas put forward. To try to rush the process means we get an incomplete picture. For this reason I have purposefully be very supportive of almost all ideas.

    Whether or not we get to the next stage of Swing 2.0 discussions is another matter entirely, for I fear that whilst there is a huge desire for the project, the time requirements and complexity would be prohibitive for the kind of people that have the skills required.

    In my private discussions with various people I would consider skilled, they have all indicated that without support from someone like Sun or similar, they would find it very difficult to dedicate enough time to see the project through to completion. The same goes for me.


  109. I haven’t read this whole thread, but I’d like to throw out a few simple items (that may have already been added):

    1) I suggest incorporating proper separation of subfocus from selection in complex components like lists, trees, and tables – ala JBCL. The “current” item receiving keyboard input has nothing to do with the selection set.

    2) The LookAndFeel system needs to be rethought from the ground-up to make for an inclusive model. Swing2 should not be a “closed” set of components (library), but a core set of components with an open model where 3rd party components get equal billing by design. This can be achieved using a “skinning” look-and-feel model like in Nimbus – but bake that notion into the lower level rather than implement a skinning LaF.

    3) Bean-binding: I agree on data binding needing to be there cleanly – but there are a lot of debates around proper binding techniques. I suggest a more formal datamodel+address based system rather than loose coupling via string expressions. Type safety and runtime metadata are very very valuable when designing usable tooling. Ping Richard Bair on this topic – he’s got a bunch of good stuff we cooked up for JSF/Creator and SwingLabs.

    I’d be happy to lend some experience, but as I’m sure you guys can appreciate… time is tight for any volunteer projects. πŸ™‚

    – Joe

  110. re doing this as an “unofficial” project–Adding support for generics/better general support for collections to the Swing data models is something I’d be interested in helping with and willing to throw some free time at.

    Something I’m not understanding is the desire to “drop” layout managers; even if you don’t like them and would prefer to do things another way, wouldn’t it be logical to simply extend what’s there? Swing already allows use of absolute pixel positioning instead of layout managers, so it should be possible to build other layout mechanisms into the toolkit.

  111. You should know that there already is somebody putting generics in swing on the openjdk project. Check the swing mailing list.

  112. One thing I would like in a new API is a change to the heavy EventListener stuff (which induces high coupling between SW components) into a lower-coupling solution. EventBus (or any equivalent) comes to mind. It would be good if Swing2 components were built with EventBus in mind (eg S2 components may push events on various named topics; these topics would be named after the component name -provided it is made mandatory in S2, which is a good practice- and the kind of event -rowselected,focuslost…

    A second interesting point I have seen in the comments here was about removing the heavy bean-style properties of Swing components. Without waiting for a language change (I doubt this will ever come one day), there are some interesting solutions out there (bean-properties on is one, but it is interesting only if it is natively supported by the components, which is not the case in Swing of course). Such a change would enable better -and easier, with less boilerplate- binding toward Components properties.

  113. Read this blog, read Danny’s blog. Haven’t touched Swing in over a year. Last touched messed with it using 1.6 and in all honesty I have never understood why people call Swing complex. Have never had to mess with Swing at a low level (e.g. overriding graphics methods, etc) so my comments come from Enterprise App point of view.

    I mean I’m doing WebDev and the difference in complexity is like “woah” (in favor of Swing).

    Swing is easy but could be made easier, as in frameworky – similar to Spring Rich. Hence the point I am in total accordance raised by Jonathan is: “Improved support for bean binding and validation”. Spot on – great observation.

    p/s: Awesome response to the Dimitry-guy. I mean I can spend my time trolling C++/GUI toolkit forums and just ripping them on how complex it is to get a screen to pop-up. What a knob!!

    1. @Kondwani: Thanks for your input. I think Swing is complex if you are unwilling to commit to understand its nuances, but then, that’s true for most things in life, particularly APIs. I think the main aim is to take what we have, and try to clean up the API. It pains me every time I’m looking for a method and it’s embedded in 100s of methods – I have to play guess the keyword, and more often than not, I end up scrolling through a huge list of methods to find the one I need.

      Things like generics, varargs, enumerations just make the API cleaner, and make it possible for our IDE, and our compiler, to help us more at compile time rather than have errors at runtime.


  114. I’ve been knee deep with Swing for … good 8 years now. And I really like it, even with all it’s quirks. Powerful tool.

    That said, I’m envious to other languages of their power. Take Objective-C as an example, they’ve got really cool properties, and creating user interfaces that sync with variables is a breeze. I’d really like to see this in Java. I think that would really take it to the next level.

    That one language feature would make recreating swing much more worth the effort. Otherwise I fear it will just be trading one bad aspect to another. To put it plain, Swing was a huge undertaking. Swing 2.0 will be huge as well. It will be defected in some ways and there should be fundamental differences that would justify the godawful amount of work.

    But I do agree with you guys, things spoken here would really mean a lot to Java.

  115. If there were one thing I’d like to see changed in a Swing 2.0, it’s the monstrous way look and feel delegates are installed. Running foreign code in the superclass constructor of your component is a horrible antipattern – and in Swing is THE pattern.

    I can’t count the number of bugs I’ve seen because of this, and bewildered programmers I’ve helped who were seeing inexplicable heisenbugs because one or another look and feel tickled a code path they hadn’t anticipated before their component was full constructed.

  116. What about the possibility of wrapping the JavaFX stuff in java so the java API looks swingish, but underneath you get all the JavaFX flexibility. This way you don’t have to deal with old legacy stuff, you get 100% flexibility in terms of how you draw your components, and users of your API don’t need to know about JavaFX (if you’ve done a good job). Also means your app will run anywhere where javaFX runs.

    The tooling for JavaFX is still pretty poor, there is a lack of components, and it’s a whole new way of programming.

    I’ve had a play with JavaFX to create a swing like GUI for editing a bunch of beans, tables, lists etc, and it toke a lot of work. Using Swing and the JavaBuilder library was much easier.

    However, JavaFX does have many cool things you can do with it, which would be cool to have access to in Swing.

    So IMHO if the two could be married nicely we would have the best of both worlds.

  117. @Bert: I’m not familiar with JavaFX – could you please point out what do you mean by “cool things” in it?

  118. I’d like to see some sort of XML layout similar to Flex. Divorcing layout and Controller makes it so much easier to modify. Easier to build WYSIWYG editors, and easier for newbies to do Swing without wrapping themselves around the axle. Better layout managers! TableLayout is fantastic so much easier to GridBagLayout, and simpler than say SpringLayoutManager.

    I’d like to see a better component lifecycle model, again this is where Flex is much better than Java. Swing as it stands makes it difficult to create properties you can adjust at runtime.

    I think Adobe’s Flex platform is a great client platform, and Java FX has got to get a lot better if thinks it can compete.

    CSS skinning, while it’s a little awkward in Flex, but something like that would be great for creating new looks easier so graphic designers can create new looks without coding ala Scale9.

    Java’s 2D library is vastly superior to Adobe’s so there is potential to capitalize on that.

  119. @Charlie Hubbard

    No XML please! Using it gives up type safety and compile time checking. It is the curse of many systems I’ve worked on and, while fashionable, is used in many places it ought not to be.

    I would prefer to work on Swing in Java *only* thank you very much. If a tool uses XML that’s fine, I’ll just avoid it or never look at the generated XML, but please don’t foist XML on users of the Java programming language as part of the Swing Core.

    For example, I consider the JPA (Java Persistence Architecture) to have bad design flaw in that at least on XML file is required, you can’t specify everything with annotations or Java code. A poor design choice if you ask me to require XML files hanging around.

    Nope, Swing should be codable in 100% pure Java. Keep your XML-hell to third-party frameworks thanks.

  120. > I’d like to see some sort of XML layout similar to Flex.

    Pivot supports UI construction via XML, similar to Flex and Silverlight.

    > No XML please! Using it gives up type safety and compile time checking.

    …but it is optional. You can also construct your UI entirely programmatically, if you prefer.

  121. I second that motion. No XML (or any other external files) should be necessary by default. If you want to use them feel free, but by default we should be sticking to type-safe pure Java code.

  122. Image management also suck. There a bazillion ways to load an image, and no component to simply display it, see

    I have read some post which look more like a thesis about “compatible” or “managed” or “intermediate” image, for example :

    this post is 30 pages long in word !!!! And I don’t understand a single word from it ! There should be only one way to load an image, and this image should be always managed in the best way possible without having to deal with such concepts.

    myPanel.add(new JImage(‘/swing2.png’));


    Image img = new Image(‘/swing2.png’);
    myPanel.add(new JImage(img));

    remove all the others things.

  123. Swing is in fine fettle and is not being replaced by JavaFX in my opinion. I am not versed well enough in JavaFX to see how well the two will integrate within one application, but it seems, we can pass processing to JavaFX if our desktop Swing apps need a browser / web 2.0 aspect. New stuff for free. I’d call that a win.

    Regarding Swing’s continued evolution, I would like to see:

    Scenegraph de-GPL’ed in the form of classpath exception , like the rest of Java.

    Graph component.

    Continued progress with FlyingSaucer. I think this is important because the future of all text is XHTML, and we need to be able to read/write XHTML. It’s more basic than even a browser in some sense.

    Continued work with Filthy Rich Clients – too bad about those guys leaving for Adobe; they’re definitely going to be missed.

    Continued work from independents in the form of widgets and tools, especially tools in Netbeans.

    Netbeans is “our” development tool (OS, pure Java, supported by Sun), and any progress there in the form of tools that makes us more productive is a force multiplier for Swing developers.

    Swing is hands down the greatest GUI toolkit in existence. Desktop apps written in Swing are going to continue to grow deeper into the longtail marketplace.

    Jackass, er, I mean AJAX, is a poor substitute for the power of the desktop; watching a AJAX application always reminds me of what Dr. Johnson’s quote ” is like a dog’s walking on his hind legs. It is not done well; but you are surprised to find it done at all. …”

    The relationship betwen Swing and JavaFX is not one of competition, its more like Java’s been extended into the whole Web 2.0 arena all at once, rather than growing there incrementally. That’s a huge win- we now own that space.

    The desktop is good for

    1)fast, real time rendering of GUIs and effects

    2)instantaneous feedback from user gestures

    3)access and processing to data people don’t want to put on the web

    That adds up to the ability to write very very rich GUIs which process local data. A local machine will always respond faster than the the same network-based processing.

    There’s no reason to think that desktop applications for which the amount of local processing is more than sufficient to render reactions to user’s actions are ever going to go away. That part of the computer is NOT the network.

    So Sun pumped some resources into Web 2.0. So how does that hurt us? It doesn’t.

  124. I have a small suggestion.
    1) make ALL constructors protected (enforced by a compile time annotation).
    2) Provide static factories for each component (that capture the generic type).
    It’s the old issue of
    Map<A> map = new HashMap<A>();
    Map<A> map =;

    plus these methods could be used for subclasses configurate things *after* the constructor is called avoiding a whole category of problems.

    I don’t know this idea might have some problems.

  125. Hey Jonathan,

    I was breeding on this multithreading issue with Swing… Would it be possible to write a GUI framework that never ever blocks the painting thread (EDT)?

    I was thinking along the approach that is used with device drivers. Each device driver usually has two separate “threads”: one the reacts to hardware interrupts and reads data from the hardware and writes that to a buffer. Very quickly, in order not to block the next interrupt. Then another thread, running in the application reads that data from the buffer. Sempahores are used to synchronize.

    Mirroring that to Swing would make the EDIT the interrupt thread. That would mean that any event that comes out of the GUI must not be running in the EDT, so a special event thread is used for that. Maybe even a thread pool, but that would introduce asynchronous behavior and Swing currently is synchronous.

    And any thread calling into the GUI components may only set a property, but that information is never propogated by that thread to the actual GUI. The component is marked dirty and the EDT does the repaint. Sempahores are used to temporarily lock a component while the EDT reads data.

    So the EDT never ever executing application code.

    I understand that deadlocking issues may be the problem here, when the EDT tries to lock a component for reading… That is where the challenge lies.

  126. Jonathan: you are 100% correct.

    One of my main historic complaints about Swing has been the horror of LayoutManagers not behaving quite like I want them to (e.g. GridLayout blowing up buttons to huge sizes). This problem has seemingly been solved: I recently did some Swing coding with GroupLayout, and to my surprise and pleasure, discovered that it seemed to behave almost perfectly outof the box. Which is the way things ought to be.

    But one confusing area for Swing, at least for me, is with the whole validate/invalidate/revalidate/repaint thing: sometimes Swing works automagically, sometimes it seems to require manual calls. Am I just a moron, or should this not all be simplert o understand and user?

Comments are closed.