Swing 2.0 – Where to from here?

So, Danny Coward has replied on behalf of Sun on the feasibility of Swing 2.0 – a backwards incompatible change to Swing. His basic statement was that backwards incompatibility is not an option in the near or medium term, but perhaps in the long term. Perhaps the major oversight in his blog post was that there has not yet been any suggestion that Swing 2.0 replace Swing 1.0 – it could be that a Swing 2.0 develops alongside the more stable Swing 1.0 branch. Through the use of differrent package names, and with the advent of Java 7 and improved modularity, Swing 1.0 can stay as-is, allowing for all existing Swing applications to continue to work. Therefore, there is no need for Swing to move from its current course.

My argument is that a Swing 2.0 brings with it reinvigorated development and a pre-release mentality to perfecting APIs, instead of simply maintaining them. Given the current state of cross-platform desktop GUI API’s, I still think Swing has a great chance of being hugely popular for the foreseeable future.

The problem is that Swing is not the primary focus for Sun anymore, which is now JavaFX. Swing will only be allow to prosper and grow if there are direct benefits for JavaFX. Whilst this is better than nothing, it means that some of the main deficiencies in Swing are being ignored. Our suggestion for Sun to consider developing a Swing 2.0 is unattractive as JavaFX is not an immediate benefactor. Perhaps the biggest hurdle for both sides of this discussion is one of inertia – to move people onto Swing 2.0 does nothing to appease the marketing side of Sun, who are shouting from the rooftops ‘JavaFX, JavaFX, JavaFX’. At the same time, we Swing developers are not keen on moving over to JavaFX, as it is not what we are used to, what we are skilled at, or ready for developing the kind of applications we need to develop. This leads to trouble – Swing 2.0 can not be seriously considered within Sun, as there is little return on investment, and at the same time it gives Swing developers time to pause and survey the GUI API landscape, to see where to reskill.

To be fair, Swing is an excellent toolkit, but it is dated and needs a refresh to keep it current. I fear that with the focus on JavaFX and RIA, there is no one at Sun really interested in Swing for the sake of desktop applications – the kind that used to be thought of before RIA was all the rage. In my personal circumstances, I primarily develop client/server applications, where the client is deployed in enterprises and must look like a ‘proper’ application, otherwise people worry. This extends to using any look and feel other than the desktop default (sorry Kirill!). Therefore, whilst I know I’m not cool to be developing desktop applications using Swing, I know my skills are relevant, as I am kept busy developing Swing-based applications. (I’m used to not feeling cool – I don’t do AJAX, and I don’t do RIA 🙂 ).

The onus has been put back on the community to develop their own solution. Perhaps one day this may be part of the JDK, perhaps it won’t. There are various projects, a number of which were discussed in my first Swing 2.0 post, that could be part of Swing 2.0. Projects (and their owners) such as Swing-Generics, SwingX, MigLayout, JGoodies Beans and Validation, FEST, all have valuable opinions with respect to their areas of expertise, and a Swing 2.0 would not be even considered were it not for these projects.

I want to refine the previous discussion. Please, regardless of whether you agree or disagree, reply to this post, but try to keep it focussed on this one aspect: Is Swing 2.0 about undertaking a major refactoring of Swing 1.0, or is it about starting with a blank slate? Let me put forward my preferred approach: I would rather take the current Swing codebase and begin a major refactoring. In my opinion, it is quicker (to get started and to see results), and perhaps easier.

In addition, if you are interested in being involved, let me know, either by commenting on this blog or by emailing me privately. To be clear though, even now, I am not suggesting we start a Swing 2.0 project, and even if we did, it can’t be a free-for-all with everyone working on it – the end result will be no better than the currrent Swing, and would in all likelihood be worse. We need an API driven by use cases and designed with very careful consideration. I do not want to rush into a Swing 2.0 without giving huge consideration to every voice out there. Regardless of whether the suggestions are part of a Swing 2.0 spec, we must consider them. Only then may we design a Swing 2.0 that we would prefer to use over Swing 1.0.

Cheers!

23 thoughts on “Swing 2.0 – Where to from here?”

  1. Hi Jonathan,

    For my part, I wonder if we cannot have a mix of both solutions you proposed:
    1- rework the current Swing codebase to take into accounts all interesting Java5 features (generics, enumerations, varargs…). Also fix some old stuff (like use of Hashtable, Vector… both in the API and internally). This way we can get results quickly as you mentioned. However the API might still be too bloated for some components
    2- then define a new components hierarchy that would delegate to Swing components, and make sure the API is not too bloated but rather “on the point”.

    Anyway the problem with solution 2, is that it starts to be a lot of delegation (swing2->swing1->LAF UI).
    I wonder if a third solution could not be: “rebuild Swing from scratch but based on all PLAF UI hierarchy”, but that promises to be painful (UIComponents have lots of back reference to their Swing counterparts and use much of their API!)

    I have taken a quick look at what the Scala team did to include Swing in Scala, this is quite interesting and it quite looks like solution 2. above: redefine a hierarchy/API which maps to Swing components; I didn’t have much time to investigate that further though.

    Anyway, if I can be of any help, you can count me in for S2 project!

    Cheers, Jean-Francois

    Just my 2 cents.

  2. I Am currently a Java EE developer but in the past I have experience with Swing and I think it is a Great toolkit. I have read the Filthy Rich Clients book so I dont think that “Swing is not for RIA”. Anyway I like JavaFX too JavaFX is great. But if sun leave behind Swing and JavaFX replace Swing it will not be good. It is good to have a nice normalno Toolkit for GUI. JavaFX is not for everything for example NetBeans is Swing app not JavaFX app and it will never be a JavaFX app. So Swing 2.0 with generics, annotations, validation, and a lot of new components will be great.

    Because I am a Java EE developer I use JSF every day. For me the best Components Suite is RichFaces. Just take a look at the demo what components we have there and check JQuery UI Components this are GREAT HTML/CSS/javaScript components they are better than Swing components WHICH IS STRANGE. So will be nice if we have in Swing all components which we have in Web environment now.

  3. I have few suggestions.
    1. There are already lots of Swing implementations. Take a look on http://www.gnu.org/software/classpath/ and http://harmony.apache.org/, and of course on OpenJDK itself. After looking on all this stuff – I don’t think it is hard to start from scratch, you just should not expect immediate results. And my java experience tells me it is very hard to refactor some old code in huge masses. There are 17800 lines of code in only three Swing classes – JComponent+JTable+JTree. I can agree that starting from scratch and taking some code parts from those classes can be effective, but taking and cleaning…
    2. Current Swing1 has lots of great features, like repaint manager, EDT, UI delegators, LookAndFeel and many other. It will be barbarism to throw it away, so may be Swing2 should be based on Swing1 or should reimplement those features itself. I am pretty sure that refactoring of current Swing is not a solution, but where to start from – from UIManager or from JComponent or something other…

    And of course if I can help – I’m in.

    PS: may be it is better to set a mailing list on s2.dev.java.net for s2 discussions?

    1. This is it exactly. It’s massively harder to interpret the code of someone else. That is especially true, as is in fact the case with Swing, that code is not all that good. Trust me, I had a compelling reason to understand EXACTLY how the JEditorPane and JTextPane components achieved their layouts. What I found in the source was shocking (to me). Parts of them read like a skilled developer was pressured by management to get something done and cranked out whatever worked at that moment of time. Imagine that.

      Good luck reconstructing the long, complicated web of cause and (far removed in both time and source files) effect at work in those packages. Understanding all that is a full-time job for a team of future code-archeologists of the 23rd century. No kidding.

      But this is exactly the problem Micro$fot has with their OS, what do they call that… Windows XP2 Special Media Edition or h1b-Visa or Vista or something? No one can understand (which means no one can touch) the underlying code base that makes things so , well, bad. Developers who THINK they can and try to cause their employer to ship stuff like Vista.

      I think this is referred to as a Big Ball of Mud. Or Big Ball of Something. In fact, much of Swing’s source is a steaming hot platter of that something. That’s what happens when management serves the gods of Wall Street and cranks something out instead of engineering solutions.

      OS groups start over completely for a good reason- it’s the only thing they can do. In the long run, OS solutions will carry the day because of their superior code quality / price ratio.

      I suggest joining an OS effort.

  4. I have voiced this opinion more than once already; Swing 2 should be runtime compatible with Swing1. This means that in a Swing 2 application Swing 1 components should be usable, but not vice versa. This is paramount for acceptance; evolution above revolution.

    This also means that S2 should use the EDT of Swing1 for painting (and I believe that to be not a bad choice, why invent everything from scratch – pick out the pearls) but rethink everything on top; painters vs UIcomponents, layouting, …

    If that excercise leads to the decision that Swing1 can be refactored, ok, but do not assume that as a starting point before fleshing out what the goal is and how to achief it. It may very well turn out that JavaFX is good foundation to do Swing2 upon.

    But you only get one chance to do it right, so get the people with experience like Kirill, Mikael, Jeanette, and maybe some engineers from Sun want to atleast contribute their experience when laying the foundation, and really think it though before starting (unlike Swing1 was). Limit that group (someone has to be able to show up for the discussion panels at J1 and take credit ;-).

    Personally I cannot pledge help at the moment; this S2 project is not detailled out enough for me and I’m not a believer (yet). I have written RIA applets using Swing and they work perfectly. But I do not know where JavaFX is going. But since I do Swing 3+ days a week, if S2 turns out to be the way to go, I’ll help.

    Tom

  5. @TBee: There will be many places, where keeping Swing 1.0 API will simply make the new API very ugly. And there is no reason for that – if you want to run old Swing 1.0 application, SUN will keep support for ever-and-day. If you will want to port application to Swing 2.0, then this should be quite straightforward but will require manual changes in code and testing and testing and testing 😉

  6. @Abraxis

    If you do not allow for migration, I do not believe adoption will be good. But please note that I’m all for a clean new S2 API, only that the core EDT thread paint thing of S1 is kept, so S1 components can be used e.g. through a S1 wrapper panel.

  7. Hi,
    I still think starting with a refactoring project of Swing 1.0 is the way to go. There are 10+ years of performance optimization in it. Don’t throw this away. But first you need a clear list of requirements before you can make a decission pro or contra refactoring or new a start.

    I’m willing to help with ideas and in a project if one is launched.

    – Bernd

  8. @Bernd

    The optimizations for speed is not generally in Swing, but in Java2D, and to some extent AWT, which Swing relies heavily on. A leaner and meaner Swing 2.0 would become faster than Swing 1.0 just because of less code cruft. Especially startup speed would benefit from a cleaner class hierarchy.

    It should be noted that writing Swing 2 would also mean either working with AWT component peers or writing a whole new OS integration layer (hard). I think the only viable course of action is to work with AWT peers. Note here that AWT peers is not the same as extending Container, Component and such. Those are the AWT components and should be dispensed with asap.

    Cheers,
    Mikael Grev

  9. My thoughts

    1. Take the bits out of swing that you wish to keep. To begin with maybe start with a delegate type implementation. Remove the concept of each component being a container and add duport for generics.

    2. Then swap out the underlying with a fresh / clean implementation that will allow the implementation to move forward to a full swing 2.0

  10. Jonathan, I do the same as you: write enterprise client/server applications. While it would be nice if Swing was revamped, I don’t see the value in doing so especially considering the effort. A better ROI will be obtained by adding missing features (like the ability to do Windows alerts) and making Swing rock-solid.

    IMHO, Swing and WinForms are good for business applications or where UI pizazz is unnecessary. For flashy UIs, go with WPF, Silerlight, Flex, DHTML, or maybe JavaFX.

  11. @Neil:
    Although I generally agree with what you said, I think the main idea of a Swing 2.0 is to reduce the painpoints (can you confirm that Jonathan?) , in particular for Swing newcomers: for someone who never worked with Swing before, writing the first application is an incredible challenge, writing it right is near to impossible. And it takes to your fourth or fifth application to build some good practice (based on your past lessons learned).

    If Swing 2.0 could remove these painpoints, that would already be a big win. At the same time, it should be good enough and bring sensitive improvements to also attract experienced Swing developers.

    Last but not least, some level of compatibility with Swing 1.0 would be required in order to facilitate progressive migration of existing Swing Applications. Providing some backdoors to Swing 1.0, although not advised for a new application, could ease this migration.

    I personally favor a delegation model from Swing 2.0 to Swing 1.0; I’d rather avoid changing Swing 1.0 API itself (but fixing boring bugs in Swing 1.0 would be fine).

    In general, I am quite happy with Swing 1.0 functionality (except for the usual missing components that we can find in SwingX or elsewhere).

  12. @Jean-Francois Poilpret: Absolutely agree. Swing is a great API, and we may be pretty expert at it, but not everyone is. In addition to minimising pain points, there are points in the API that just make me feel a little dirty using – as it makes my code dirtier.

    Examples are numerous, but the ones that particularly rile me include:

    • Using Vector, when all my data is in List (and more commonly it is implemented as an ArrayList),
    • Having to pass an array of Object when varargs would be nicer.
    • The consequent need to cast an Object to it’s actual implementation / interface when doing a getSelectedObject or similar method.

    These are only a few examples. In addition, I would love to see clarity around EDT rules. My preference would be to absolutely, without option, enforce strict EDT compliance. Anything that should operate on the EDT that does not, or anything that operates on the EDT but is taking too long, should result in a RuntimeException. As I always say, programmers may hate it, but just think of it as EDT-Pokemon – you’ve gotta catch (and squash) ’em all!

    A delegation model make sense. I have absolutely no aspirations to change the Swing 1.0 API at all. In this regard Swing 1.0 should continue on its current course. Swing 2.0 is about cleaning out the Swing API in a different package. It is also about being Swing-like, as if we aren’t Swing-like in our structure, we might as well move to another API toolkit such as Pivot or JavaFX 🙂

    Jean-Francois, thanks for your many well-considered comments – they are much appreciated and always add much to the discussion.

  13. Yes Jonathan, for sure I would like to see all these Object[], Vectors and other Hashtables removed from the Swing API (it would not be bad to remove them from Swing implementation as well, since synchronized List/Map doesn’t bring anything in a Swing context, as long as you follow the EDT rules).

    I also would like to see meaningful enumerations everywhere we have those terrible Swing int constants!

    For EDT rules, yes I agree to enforce it, however it has three potential drawbacks:

    1- reduce migration ease (how many existing Swing applications don’t respect these rules?) and hence adoption

    2- for long tasks in the EDT, I am not sure it is that easy to force an RuntimeException on a task executing in a thread you cannot control much. Trying to interrupt it from a watchdog thread won’t work in all situations (only some operations are interruptible in the JDK, I/O for instance). And stopping the thread is a NO-NO. So we would have only a “best effort” solution here: if the long task calls interruptible operations it will be interrupted and we should be able to force a RTException, else nothing will happen until the task ends. On the other hand what we could do is measure the time it takes and throw RTException after the task has elapsed (so the developer has to fix it).

    3-There is a risk that some tasks are always quick during development and tests, but get slower in production (testing environment can never fully reproduce real production conditions), throwing an exception in this case would be very bad. Hence it should be possible to disable this mechanism for production.

    In addition to the above, what I really would like to push is to totally remove the “JavaBean-ness” of Swing: I’m a bit fed up of get/set/addListener/removeListener/PCL all the way. Although we cannot count on language property support for a long time, I would really favor one of the existing open source options out there (I like the “beans-properties” approach a lot, although I have never really played with it). With this, binding to widgets properties would become a breeze. If your own beans were also using the same approach then binding them to widgets would also be simple.
    – Gain: less boilerplate code and, more important, compile-time safety.
    – Risk: integration with other libraries or frameworks (persistence comes to mind)

    I would also replace Swing “high-level” events listener (ActionListener, SelectionListener…) by an EventBus approach. We could also add new kinds of events where we feel this is missing in some components.
    – Gain: low-coupling
    – Risk: keeping track of what listens to what events that are generated by what (common problem with EventBus usage, but there are some solutions).

    Once the main options for Swing 2.0 are selected, the hardest work will be to plan the design/implementation in such a way that helps the community “see” the progress, that’s really the hardest part because, if we have to work for one year full without any -intermediary- results, people will leave to some location where the grass is greener;-)

    One thing I had in mind was to do something like that:
    1- define the minimum API of the root components (namely 2 of them: widget and container, or whatever name fits better)
    2- create the first concrete widget by hand (eg a Button) as a Proof of Concept
    3- then create a generic “wrapper” widget (that delegates to any JComponent and that can reflect all its properties and listeners). Although not perfect, this would allow to easily create widgets mapping to all main Swing components. Then, we could choose which components we don’t want generically wrapped but rather specialized (for easier use). This generic wrapper would be kinda temporary in the development process, eventually all Swing components (and other important 3rd-party components) would have their own widget class. The generic wrapper could still be kept in the library so that developers can use it to easily integrate other existing components (which may be closed source).

    OK, I think that’ll be enough for today (I have other important & urgent tasks on my todo list for this week-end;-))

    As someone else suggested, it may be good to open some mailing list on the S2 project on java.net (or a wiki).

  14. Hi Jonathan,
    I follow this discussion for some time now and there seem to be two groups with different opinions and targets. The one group is quite happy with Swing and does only want to cleanup the API and make things nicer. The other group wants to build a new framework with a new feature set in their mind (painters, validation, layers, new layout logic, …) For this reason the discussion is a little bit going back and forward.
    I think it would be really helpfull to set this up in a more structured way. perhaps a project wiki to list up all ideas and criticism. A poll for “Refactor” / “Start new” or at least a mailing list.
    people that want to join this discussion have to read comments of multiple blog entries to get into it.

    @Mikael
    I know you are one of the “Do it right” group. You are absolutely right that most of the performance comes from Graphics2D but there is also a lot of optimizations inside of the Jcomponents and UI delegates. It is not only the performance it is also the thousands of bugfixes gone into Swing, the stability. And I think it would be really important to give the people an easy and clear migration path to a new framework. This would be easier if Swing 2.0 would be build on Swing 1.0 or would at least be able to integrate Swing 1.0 Components.
    My interest is to build good looking business applications with a stable, mature and well known API so at the moment I’m more in the “Refactoring” group just because I cannot think of myself to do it better than the original Swing team has done. But my mind is open for both directions.

    – Bernd

  15. @Jonathan
    The new hosting project from sun – project kenai http://kenai.com – looks also very promising. The website feels more responsive than java.net and it features subversion and mercurial as SCM. This would enable to clone the original swing repository for the start and maybe easily merge bugfixes from Swing 1.0 – where applicable.

    Regarding the topic evolution or revolution. In my opinion it would be preferable if Swing 1.0 components could be (re-)used. Otherwise such great libraries as JFreeChart could not be used or have to be converted. Maybe the “wrapper” widgets that Jean-Francois has proposed would be a way.

    Anyway, I think starting from the existing code base and using existing example is a good idea.
    The examples cold then be converted into the intended API and serve as a testbed.

    Marco

  16. Here’s my suggestion for Swing 2:

    Please study Delphi and learn from it’s success on desktop development.

    In my point of view, what makes Delphi success was:

    1. Small but very useful language cookie for desktop development. Mostly important was direct property and event support. Compare to getter and setter, event listener in Java, direct property and event support will make the code much more cleaner. Please also check Java implementation, http://code.google.com/p/javabuilders/, it have similar design philosophy with delphi. Please drop the silly idea of solving any problem with Class and Object.

    2. Great custom component infrastructure. Javabean infrastructure is not a complete component infrastructure. It just finished some basic work, but far from complete. It also require smooth IDE support.

    Please hire or consult some delphi guru to design the Swing 2.0. They were real experts on desktop development business.

Comments are closed.