posts/2009/swing-20-where-to-from-here/index

[JonathanGiles]

Swing 2.0 - Where to from here?

https://jonathangiles.net/posts/2009/swing-20-where-to-from-here/

[JonathanGiles]

Auto-imported comment, original author: Jean-Francois Poilpret Comment posted on: February 6, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: JOKe Comment posted on: February 6, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Aekold Helbrass Comment posted on: February 6, 2009

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?

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: February 6, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: February 6, 2009

@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 ;-)

[JonathanGiles]

Auto-imported comment, original author: codecraig Comment posted on: February 6, 2009

Have you looked <a href="http://griffon.codehaus.org/&quot; rel="nofollow">Griffon</a>?

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: February 6, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Bernd Rosstauscher Comment posted on: February 6, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: February 7, 2009

@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

[JonathanGiles]

Auto-imported comment, original author: Ryan Henderson Comment posted on: February 7, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Neil Weber Comment posted on: February 7, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Jean-Francois Poilpret Comment posted on: February 7, 2009

@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).

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 7, 2009

@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: <ul> <li>Using Vector, when all my data is in List (and more commonly it is implemented as an ArrayList), <li>Having to pass an array of Object when varargs would be nicer. <li>The consequent need to cast an Object to it's actual implementation / interface when doing a getSelectedObject or similar method. </ul>

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.

[JonathanGiles]

Auto-imported comment, original author: Jean-Francois Poilpret Comment posted on: February 7, 2009

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 &amp; 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).

[JonathanGiles]

Auto-imported comment, original author: Bernd Rosstauscher Comment posted on: February 7, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: February 7, 2009

To all - I have set up the <a href="http://s2.dev.java.net&quot; rel="nofollow">http://s2.dev.java.net&lt;/a&gt; project. I will try to set up some mailing list or similar for more proper discussions tomorrow. If you have a better/preferred web hosting platform, please let me know.

Cheers, Jonathan

[JonathanGiles]

Auto-imported comment, original author: Marco Zuehlke Comment posted on: February 8, 2009

@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

[JonathanGiles]

Auto-imported comment, original author: spiker Comment posted on: February 9, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Aekold Helbrass Comment posted on: February 12, 2009

It's strange, I can't remember delphi was success...

[JonathanGiles]

Auto-imported comment, original author: swv Comment posted on: February 13, 2009

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.