Saturday, December 27, 2008

Should we fork swing-layout project?

The swing-layout project was the initial effort to bring Swing a better layout system that would in particular take into account the specificities of the installed Look & Feel, alongside baseline alignment support.
Swing-layout works with Java5 (maybe Java1.4, I don't know, I have never checked).

This is where the new Java6 GroupLayout has been elaborated before integration into Java6.

Besides bringing a new LayoutManager that provides better layouts (at the expense of higher complexity in use, except if you use NetBeans Matisse designer), swing-layout also brought utilities available to other third-party layouts, in particular the aforementioned baseline support.

DesignGridLayout is one of those LayoutManagers that relies on swing-layout for baseline alignment. It is also one of my Open Source projects.

Swing-layout was available before Java 6 and, of course, the release of Java 6 has made it somewhat irrelevant (at least for the rare developers who could jump to Java 6 immediately).

Now it is strange to discover that Java 6 baseline support is better than swing-layout itself (when using Java 5). Indeed, the swing-layout project on has been left in limbo for about 2 years, and it looks nobody is really responsible for it, several issues are still open and nobody cares!

So what should happen to this project? Should it definitly be buried in favor of Java 6?
Or, stated differently:
Do we necessarily need to upgrade to Java 6 to have good Swing layouts?

I don't think so! Java 5 is still mainstream nowadays, and it is planned to reach EOSL in one year (that's still some amout of time!). So I strongly believe Java 5 users should not be left behind.

Why do I talk about this topic here? As a matter of fact, I have hit swing-layout bugs in DesignGridLayout and I am facing a tough decision:

Should I leave DesignGridLayout Java 5 support behind and require Java 6 as a minimum?

Or should I try my best to keep Java 5 support -with no difference in the provided features- at least for one more year?

If so, how should I deal with swing-layout bugs?

One idea I had was to fork the swing-layout project and create my own, with the same license (LGPL). Although it seemed to me a good idea, the problems I got with this is that:
  • I don't have the facilities to test all cases (MacOSX, Linux GTK)
  • I don't have much time left for Open Source (I already have 4 OSS projects and I can't deal with them all, I always have to put one in top priority -currently DesignGridLayout- while the others have to wait, sometimes for several months)
  • I don't want to support GroupLayout which I don't use and which is a competitor of my own DesignGridLayout!
Indeed, yesterday I have refactored the whole baseline support in swing-layout (because currently everything is in one huge class with a lot of terrible code, very difficult to maintain and extend). I have fixed the two problems I have in DesignGridLayout (JScrollPane and JTableHeader baselines). This works but I don't know yet if I'll keep it (because it is LGPL and DesignGridLayout is Apache License 2) as part of DesignGridLayout source code.

Thus I think that, unfortunately, I'll have to throw away this code (is there someone interested out there?) and try to stick with the "official" swing-layout release and find some workaround that can be implemented directly in DesignGridLayout as a caller (no license incompatibility).

Of course, if someone is motivated and ready to take over the effort of forking swing-layout, then I would happily give back my work to that new project. Just drop me a note.

The rant

Now the status of this library, sponsored by Sun, reminds me of other "currently on-going" (:->) efforts such as: JSR-295 (beans-binding), JSR-296 (Swing Application Framework).
Once again, although Sun claims they don't leave Swing behind, they actually do, in favor of that half-baked JavaFX thingy, which is not even comparable to its competitors, which we may wonder if it deserves the "1.0" version number. Layout support in JavaFX made me laugh big times (it all boils down to HBox and VBox).

Maybe it's time to start forgetting Java (and Swing?) and learn something new (anything but JavaFX).


  1. please don't leave out java5! at least not until we can safely run java6 on macs.

  2. Hello Andrew,

    finally I have made up my mind and decided to implement a baseline workaround directly in DesignGridLayout itself(it is not very beautiful but it works).
    Everything is currently committed into SVN trunk of the project.
    I just hope that Java5 users of DesignGridLayout won't hit other swing-layout bugs because I am not sure I would be abe to work around them all the time.