posts/2009/sun-responds-to-swing-20-discussion/index

[JonathanGiles]

Sun responds to Swing 2.0 discussion

https://jonathangiles.net/posts/2009/sun-responds-to-swing-20-discussion/

[JonathanGiles]

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

My feeling from the Sun's message is "We will add a component here and there, fine-tune the speed, but that's it".

I'm afraid, that they simply don't get it - many Java applications are boring (read: no need for fancy JavaFX effects) and developed for a few customers or even users. For this usage is the Swing good fit with some small-but-annoying issues - which can't be fixed without breaking current API.

[JonathanGiles]

Auto-imported comment, original author: Bob Comment posted on: February 5, 2009

It sounded like one big non-answer to me. I didn't really see anything new added to the discussion. What I took away from it is... "We'll maintain it to some extent for the sake of all the legacy code out there, but we're pretty much done with it. If you guys want any new stuff, you can contribute through OpenJDK."

[JonathanGiles]

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

Yes, they really saying "guys, we are with you, but we will do nothing". There are few things I cannot get.

1. What is the trouble of backward compatibility? If you wrote your application for JDK4 or JDK5 - you can still compile and launch your application with this version of JDK, you don't need to download JDK7 and use it's features if your main target is backward compatibility. If you need new features - there are millions of frameworks for Java with backward compatibility which you can use for your old application, no need to get JDK7 any way.
2. Nobody asks to break existing Swing, talk about Swing 2.0. If you starting with new framework there is no need in backward compatibility, swing 1 can be backward compatible with itself until the doom's day come, while javax.swing2 does not need to be compatible with javax.swing.
3. There is no leak of possibilities, there is only leak of imagination. Thinking about 5 minutes you can get 10 ways to make jdk backward compatible while developing revolution in next jdk version.

Summarize, I can't see any REAL reason why not to do Swing 2.0 for Sun, the only think I can see - they just don't want to bother because they don't need it, current situation is suitable for them. It is pain for me to admit, Qt with Jambi moving much faster, and there are no issues with backward compatibility...

[JonathanGiles]

Auto-imported comment, original author: Porfirio Comment posted on: February 5, 2009

I kinda understand their position.

But still believe that a Swing2 is possible, and with project jigsaw it would be possible to add it to openjdk without making it more bloated than it is right now.

We have many Swing experts out there that spent many hours to fix swing to make it work with their applications.

Many of them wont mind to help in development of Swing2.

Maybe a discussion forum could be created where people could post what they miss on Swing and what they want changed on Swing2, and let other people discuss how to make swing better.

[JonathanGiles]

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

To all, I did set up a java.net project at <a href="http://s2.dev.java.net&quot; rel="nofollow">http://s2.dev.java.net&lt;/a&gt;, but I am not seriously pushing it at the moment. Whether that site may eventually be used, I don't know. If you feel inclined, please feel free to post there.

-- Jonathan

[JonathanGiles]

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

Take a page from Apple and make the transition between Swing 2.0 and Swing smooth. The learning curve needs to be short.

Backwards compatibility is always a mistake in my humble opinion. Just facilitate the transition. Automate it if you can. Refactoring in Java isn't that painful.

When XML cropped up and people were writing backwards compatible schemas, I thought it was a joke given XSLT provides an easy facility to transition from one version to the next, keeping the schema itself clean and straight-forward.

This principle could apply to Swing 2.0 as well.