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 πŸ˜‰

Comments are closed.