Sun setting down on the core Swing
November 5th, 2008 | 38 Comments »Core Swing is in the process of being retired as a legacy UI technology inside Sun, and last week has marked another sad (yet expected) milestone. According to Jeanette Winzenburg‘s post on the SwingLabs java.net forum, Sun has stopped funding of the SwingX project.
Announced at JavaOne 2004 under the JDNC brand, SwingLabs has been widely considered as a breeding ground for modern UI technologies (new components, markup language, binding etc) for later inclusion in the core JDK distribution. It has enjoyed significant attention from the Swing community, drawing dozens of outside developers to contribute code and discuss various approaches to provide modern, rich and customizable components. Perhaps the culmination of these discussions happened in 2006 around the painters. The community members (IMHO) have truly believed that SwingX is being officially regarded inside Sun as a gateway for those contributions to find their way into the core Swing, and the level of excitement was clearly visible throughout the well argumented and heated discussions about the painters.
In my view, the turning point has come in January 2007 when it was announced that Sun unilaterally has decided to remove the entire painter layer from SwingX. This has effectively destroyed the trust of external contributors, who never came back, even after Sun developers have retired themselves from being involved in the project. In this light, Amy’s comment on Jeanette’s thread is a little misguided:
SwingLabs isn’t being shut down and SwingX isn’t going anywhere — it’s a great extensions library that exists because the community drove the development in the direction they needed. I don’t see that ending.
In fact, that single internal decision that completely disregarded the whole year of discussions was the most unfortunate moment in the project’s history. Looking back, it is even more unfortunate since SwingX components are not going to be part of core Swing (more on this later). Up until that moment the community has believed that it had an equal say in the development direction. After that moment most of the community has left, and a few months later Sun has decided on the new direction – JavaFX.
I don’t know what the future holds for JavaFX. Sun is heavily betting on it, and nobody wants to have their Nomad moment forever archived on the Internet. All i know is that JavaFX has effectively halted all core Swing development. Over the last 18 months, we have seen significant architectural initiatives (JSR 295 and JSR 296) changing leads and frozen. All client-facing improvements in Java2D, AWT and Swing in Java 6 Update 10 are completely driven by the requirements of JavaFX. In Richard’s own words (the same thread on SwingX funding):
Swing is part of the JDK. It isn’t going away any time soon. For a great many large enterprise applications Swing is the best cross platform toolkit available. We’ll continue to support and work on fixing bugs in the JDK.
It can’t get any clearer – the only two active areas of Swing core work is support and bug fixing. You might say that things will change once JavaFX 1.0 is out the door, but this is quite unlikely. JavaFX has a lot of ground to cover if it is to compete with Adobe and Microsoft, and it has even more ambitious plans for mobile and set top environments. In Richard’s words:
Definitely no question that there is a lot of working going into JavaFX and will continue to happen.
What do i see happening? I think that the current core Swing feature set should be considered frozen, until shown otherwise (not in words, but in actions). Swing is an extremely well written and customizable UI toolkit, and it is a solid candidate when you consider writing your next UI application. However, the innovation must come from third-party developers, be it binding, application framework, components or markup language. As the Swing Links trail on this blog shows, there is a lot of external activity in this area.
I think that core Swing has become a victim to Sun’s outdatedly rigid policy on the backwards compatibility. I have written about this topic in the Substance users mailing list a few weeks ago:
The eternal fear of Java core libraries is to never break existing applications (by the way, the Swing forums are rife with examples of applications that break when migrated to a newer JDK versions; it doesn’t have to be EDT violations, something as simple as event firing condition due to a bug fix is enough). This fear has us stuck with Ocean as the default look-and-feel. This fear has us stuck with tons of deprecated APIs that unnecessarily complicate the learning curve for the novice users (how many ways to catch an Enter key on text field?) This fear has us stuck with obsolete layout managers (gridbag, spring). And by the way, this fear also prevents the core developers from adding new functionality out of the fear itself that they might get it wrong the first time and get stuck with it forever.
Like i said before, in the grand scheme of things, it all doesn’t matter. Technologies die, new technologies are born, people move to other companies, old prejudices refuse to die and some decisions are forced on technical people. The customers, of course, couldn’t care less about all this.
Related posts:
- Flamingo ribbon component: support for core Swing components The latest addition in the Flamingo component suite is support for core Swing components. This...
- Advanced animations on core Swing components – part I Animations are most probably one of the main ingredients of a modern UI. This applies...
- Advanced animations on core Swing components – part IV This is the fourth part in the ongoing series about advanced animations on core Swing...
- Advanced animations on core Swing components – part II The first part showed the animations added (among the rest) on menus, sliders, tables and...
Thanks for stopping by. My name is Kirill Grouchnikov and I am a user interface engineer. I have been doing client side development professionally over the last decade or so, in a variety of UI toolkits and libraries that spanned Motif, MFC, VB, Ada, Delphi, Swing and SWT. Recently I joined the
This is exactly why this quote “Sun used to sell bits. Now you’re selling trust. Interesting times!” – from http://blogs.sun.com/superpat/entry/selling_trust – made me laugh in kinda sad way.
The foggy direction of this top Swing project is another reason to choose something else :(
Thanks for Substance Kirill
Sun has lost the battle on the client and now it tries to catch up with JavaFX, instead of focusing on Swing and try to make it simpler. Very sad, if you think that JavaFX is nowhere near where Flex.
As someone with investments into both JSR-296 and the great widgets of Swinglabs, these recent events saddens me. Swing always were an underachiever but at least with Swinglabs we had a datapicker and other useful stuff that core Swing oddly never had.
One wonders just how little money Sun has in the bank, for them to kill of something this prosperous – Jeanette and Karl have always met us, the community, with open arms. Indeed, to an outsider, SwingLabs looked like a real bargain for Sun!
As I said in Janette’s thread. They’re afraid of breaking backward compatibility. They think:
- JavaFX is a new language, so nobody can blame us for breaking any backward compatibility.
- Now we can add properties (in the form of binding) in that new language we have.
- Boss, do you think we can add closures in JavaFX, JavaScript has it ? Nope, let’s stay under the radar.
What Swing needs:
. in Java: closures and properties (watchable properties for simple binding)
. in Swing: major code-breaking refactoring and painters. Look at Flash’s ActionScript 3 class hierarchy (not even Flex)
I think I should give a look at Pulp Core (love the demos)
This will kill the best Multiplatform GUI framework that is right now, It is dumb what is doing SUN and promoting an ugly and stupid Javafx scripting language. Swing is Open Source? so we could continue to contribute and make Swing a better framework because SUN failed in that since the 90′s.
I think Java is done for the client side, It is only a server side language, The only solutions for the client side I see is C++, C#.Net/WPF and maybe Python with a binding or Flex and Silverlight.
I think for the client and desktop development I will comeback to C++.
So long Swing, It was great all this years.
As someone who has spent a considerable amount of time and energy with Swing, this post has left me with a queasy feeling in my stomach. I can’t say I’m surprised though. I think the writing has been on the wall for some time.
Realistically what is the outlook for Swing? Will it fade into obscurity, or perhaps someone else will take up the mantle?
I read the post is the issue with SwingX not Swing itself. Swing is not going anywhere soon and after getting past the initial issues (binding, threading etc) I find it very easy to build a large complex information system – with a relatively small number of hours compared to the equivalent (and numerous) web application initiatives. Having a pure Java application – client and server makes life much easier.
I can understand the issue with SwingX – some things (like the painters) I found a little buggy when used in production and have pretty much scaled back so the only thing I use from that project is JxTable (I think … :-).
The pendulum swings between fat client and thin client applications, as processing power becomes obscene I think the need to build applications does not make sense for power business users – certainly Google Documents has a long way to go to catch up with MS Word.
I think JavaFX has great potential and I am keen to extend my open source EMR to mobile devices using that technology – as soon as the desktop version is mostly done…
What is sad for is the the fact that they didn’t break backwards compatibility in order to have a better API as new releases of the JDK appears. Swing is fine for many and will not need to change much to adapt to the needs of users for the coming years in some areas in which you need desktop applications.
As I mentioned many times to whoever would listen at sun, please just buy jidesoft, roll it in, and be done with it. it starts to look silly now.part lack of 3rd party ecosystem, part learning curve, part lack of focus, and part lack of higher level abstractions for apis so developers don’t have to think too hard unless they want to, mixed with lost opportunity.
The community could step up now that it’s open source. I am sure that there are 10,000 businesses with swing frameworks who could pitch in 100$ a year license.
All it would take is:
1. Global rename javax.swing -> java.momentus or something similar. Start afresh while building.
2. Extract interfaces from swing components to enable creation of a low-level, multi-rendering system (e.g. swing + gwt).
3. Refactor swing models (extract super interfaces of listmodel/comboboxmodel etc, use collection methods — get instead of getElement etc).
4. Pull up data into a separate interface (e.g. TableData -> TableModel ) Models should provide listener specific functionality on top of data. This is for serialisation.
5. Remove dependency on awt.
6. Remove the need to have customised filechoosers: just use the native ones!
Seriously, I know that people would pitch in. A refactored, non-backwards compatible, but easily switchable competitor to swing would be welcomed.
I started learning Java seriously only a few months ago but also from my point of view Swing is the most attractive multi-platform GUI technology around.
I cannot see any logical reason for closing down that project. I understand fear of breaking backward compatibility, I have that also all the time. But this should be an indicator to just pay attention when programming. Fear should not grow so big to stop development completely.
And what about new technologies? Are they working well right from the beginning? I have seen plenty of new software(-libraries) with bad design. And I do also see an end of the web application hype as web applications are not the magic pill that solves all problems.
Totally agree with ben. But sometimes it is better to start from beginning and copy interesting code but not to clean the beast like Swing is, with all deprecated and legacy methods.
Late to finding this via java.net, can I be excused as their javadesktop community rarely sees updates these days. Needn’t have posted most of my response to http://forums.java.net/jive/thread.jspa?threadID=52945&tstart=0#315230 seems every things been said before. Yeah the threads spilt on the swinglabs forum.. Can’t get the staff these days ;)
[...] 6, 2008 by John So it looks like Sun aren’t going to do any more work to enhance or improve Swing. It’s kind of sad, but not entirely unexpected. I can’t help feeling that multiplatform [...]
This feels like a big bomb dropped on me. I had no idea the Swing world was falling apart like this. I know that there were a couple of Sun employees here and there that left the Swing department, but I didn’t know it was because of this.
I don’t know about anyone else here but I am now really glad that IBM developed their own swing-free toolkit. Eclipse RCP may be the best alternative out there to swing for java developers with regards to real desktop apps not just toys or conference demos.
I’ve been writing real world commercial Java GUI apps for years now. I think Sun would be suprised just how many organisations actually use the Swing set for real world demo’s. I’ve developed all sorts of applications based on it, from Mapping clients (like google earth and maps), to warehouse control front ends.
Once Sun start to lose developer confidence it will be a slippery slope they will struggle to recover from. Not one of the companies I have developed for is the slightest bit interested in JavaFX, who is going to use it ? Not the same people who want Swing front ends and there are a lot of them out there.
Didn’t mean to put the demo’s bit in the last comment I meant real world applications. However saying that it is great for fast prototyping, especially when sat with the customer with Netbeans running and showing them what they will get.
I doubt that Sun will totally give up on Swing. Swing is still only GUI toolkit that bundle with Java runtime, and I do not see why Sun will kill it consider that it is still the most popular Java toolkit.
My opinion is that it is premature to say that Sun abandon Swing in favour of JavaFX. Rather it is more that Sun, in the midst of financial pressure, currently direct Swing resources on JavaFX to hasten its release. There are things that JavaFX does well using node-based approach,and things that only Swing can accomplish using component-based approach. There is no question that Swing still rein over JavaFX when it comes to develop traditional or control-rich desktop application. This has always been clarified by Sun engineers.
I always feel that SwingX has never been officially endorsed by Sun even though some features eventually make its way to standard Java environment. No disrespect to those talented engineers of Sun and the commenters,I actually glad that Sun realizes that it is time to consolidate and focus resources to finish work on specific technology (JavaFX in this case) to produce a product before moving to next technology.
Sun engineers have the propensity to work on pet projects and then move on without releasing them officially (non-beta or non-experimental, eg Swing Framework). This kind of flip-flopping mindset has to be changed in order for Sun engineers to be taken seriously. If Sun pulls through JavaFX, it might be able to focus more attention on fixing Swing.
As for why not improve on Swing to make it simpler, I do not think Swing can be made simpler to use consider its sophisticated architecture, flexibility and API. It will be hard to transform Swing into something it is not. That to say, Swing does benefit from incremental improvement like Nimbus, Java2D enhancement etc.
To me, it looks like they’re spitting in our face.
We *are* the ones sticking with swing and client-side java, even after everything ! I surely don’t need to remind how bad the client side state was/is, and we stuck with it anyway.
We’re evangelists, and obviously pretty vocal at that, as the discussions (over the years) show.
I see this little PR crisis – which they don’t need and to my eyes can’t afford really – as the culmination of years of neglect, then not listening to us, and finally not even talking to us anymore, like in a fading marriage (e.g see the irony of javafx being developped in a closed workspace when it’s called *open* jfx), since the beginning of the whole javafx story.
This is weird, as client side developpers, one might think that this client-side initiative would be at least interesting to us, developed for us, tailored to our needs, the ones that have been shaped by the years of experience on the whole subject, and watching with envy the other technologies deliver user experience we can only dream of doing right now. Who knows maybe in the 2+ years it took to build it (and it’s still not done) we could have helped…
“Sooooon” (quote from the same swingx funding thread) we’ll know what the high council has decided that we actually need to do our jobs properly.
I say at the very least the plans need to be public right now. Not in a week, not in two weeks not when javafx is released (which should be “sooooon” – i took a bet on a 1.0 release close to the 1st week of december, and 1.5 between q1 and q2 2009). Since they’re supposedly so grand and majestic and awesome, this would be the right info (almost the only one we would have had about the project) to come out right now to solve this PR issue.
I think it goes much further, as i said in my first comment they’re supposedly selling trust right now, but i’m about to shop elsewhere.
Do they even care ?
I do not see how legal or other issues that stopped SwingX funding stopping means abandonment of Swing Core.
Hi,
there is a healthy discussion with Sun key engineers about this misconception in
http://weblogs.java.net/blog/editors/archives/2008/11/swing_swing.html
The following are some of the interesting comments from Sun Engineers
================================
Hi guys. This is Josh Marinacci from Sun.
We’ve all been very busy working on the JavaFX 1.0 release, so we
haven’t been as responsive on the mailing lists as we should. I’m
sorry about that and we’ll try to do better going forward. I would
like to clear up some misconceptions regarding Sun’s support for Swing
and SwingLabs.
* Is Sun canceling SwingLabs? No. SwingLabs and it’s mission
haven’t changed. There is still a need for high quality open source
Swing components, and SwingLabs still exists to do that. It hasn’t
been canceled. Richard Bair even has a BOF scheduled for it next month
at Devoxx.
* Is Sun stopping work on Swing? No. Swing continues to be improved
as you saw in Java 6 and will see in Java 7. Due to the nature of the
JCP process we cannot add new API features in update releases, but you
will see new stuff in Java 7.
* Is JavaFX taking away from Swing? While we have temporarily shifted
some resources to focus on the upcoming JavaFX 1.0 release, Swing
remains a crucial part of the client Java platform. JavaFX even
allows you to mix Swing and JavaFX graphics nodes in the same
application to do some very cool things. We’ll have a sample at launch
which shows you how to do this.
* Are you going to improve Swing? Actually, we already have been!
Much of the work done recently has been in JavaSE 6 update 10. Most of
these improvements benefit Swing applications as well as JavaFX ones.
Things like the new robust applet plugin, the new Nimbus L&F, better
hardware acceleration, and the better Java install experience. These
are all features which make the life of a Swing developer much, much
better.
As a life long client Java developer I have never been happier with
the current state of the Java stack. Client Java applications are
becoming faster, more reliable, and easier to develop. And this is
true for both Swing and JavaFX applications. Stay tuned for the 1.0
release of JavaFX. I think you will be happy when you see what we’ve
been working on. It’s an exciting time to be a GUI app developer on
the Java platform.
Thank you,
Josh
===========================
Richard Bair
- JavaFX isn’t just for web developers
- JavaFX != JavaFX Script
- Flex is built on Flash, and is of interest to enterprise developers. Why would JavaFX libraries built on top of JavaFX not be of interest to enterprise developers?
- JavaFX isn’t a web based tool. It is just like java — run in browser, out of browser, on mobile…
A lot of this angst is premature, wait until the releases and roadmaps are made public (sooooon) before throwing tomatoes at me at Devoxx .
I know Swing, I know app development, I sympathize and completely understand the mood of the Swing community (having come from the Swing community & app development before joining Sun). I know the limitations of Swing and also the really great flexibility and features.
A number of my friends and colleagues have moved on to Google or Adobe or other places (some of them simply for a change). I could have gone too. The reason I’m here at Sun working on JavaFX is because the scene graph APIs and other platform APIs we’re working on are *really* exciting. They excite me as a Swing developer. Many many things we wanted to do with Swing but couldn’t, that we wanted to do in SwingX but couldn’t, we can do in JavaFX. I don’t think I can emphasize this enough. JavaFX (and I don’t mean the language!) gives us power and freedom that we’ve not had in 10 years.
Sun is pouring a lot of resources into the client right now.
Will there be an interop story between JavaFX and Swing? Of course. But some of these things will take some time — a few months maybe, I cannot say for sure until our roadmaps are public, but obviously it would be folly to chase a new market and ignore our current market. That’s not going to happen.
================================
Swing is still much alive as it seems.
Guys,
1) Be glad SwingX won’t make it into core Java. This means you don’t have to worry about Sun’s excessive backwards-compatibility policies.
2) The community needs to “step up” and provide a 3rd-party *mature* GUI API. SwingX came out with beautiful components but it has no release schedule and absolutely zero API freezing (again because there were no real official releases).
We need something like Netbeans or Glassfish for Swing, where the community works alongside Sun but we are free to break backwards compatibility (within reason) in order to provide a better product.
Has anyone actually got any of these so called cool demo’s to actually run with any performance ? I’m using a damn quick machine and they seem to run like a dog. I could code similar things in Java2D and they would fly.
Anyway back to Swing, I think its about time Sun told us all whats going on. I know the last company I worked for got wind of some of these online discussions today and it has spooked them. They have already started discussions on future ways forward. Just the tip of the iceberg if all these rumours carry on with silence from Sun.
[...] abandona Swing Encontre esta nota “Sun setting down on the core Swing” en el blog de Kirill Grouchnikov. La noticia me desconcierta ya que Swing es un framework [...]
For years I’ve been saying that they should JARalize the JRE, because Java in essence is a virtual machine with a huge amount of libraries. So Swing is also just a library. And it has it deficiencies (maintly because of a too quick release). I can’t tell you how often I have though about writing my own JTable…
There os nmo reason why there can’t be a healthy open source component development partially based on swing. JxTable extends JTable, but you also could have a whole fresh implementation. This would also cope with backwards compatibility; simply make a JNTable as a new version and keep the old one.
That said; it’s always bad when a strong force is losing focus. But let’s see first what this whole JavaFX brings us and what will happen in the future.
Guys, don’t panic – Swing is here to stay…
The announce of Sun stopping funding of SwingX is spreading some irrational fears. I’m in the worst moment to blog about that, but I’d like to put some things clear immediately (for this reason I’m not commenting on Kirill’s blog……
Swing is already a mature platform with countless investments on top of it in the industry. Simplifying or remodeling is out of the question because it will either break the backward compatibility or make Swing bloat to the sky even more. Bug fixing and stabilizing efforts are ,to me, good enough. There are plenty extension libraries out there to choose from.
The point is do not blame Sun for consantrating on another innovative(I guess) tool by leaving Swing avengalists a little out of the frame. If you think that your years of contribution or classy status as a swing developer or expert is going down the tubes, that is going to be neither Sun’s or JavaFX’s problem.
Once upon a time, I was a prestigious X/Motif expert myself. It was before the arrival of Java platform and Swing to the market. The change is not always easy but need to adapt.
Kirill, I believe you’ve said what matters most: Technologies die, and new ones resurrect, People leave their companies for another just because they don’t seem to believe in the vision again and also for other reasons; which I think is what is currently happening here. We don’t need to start mentioning names here before we realize that the fore-runners that Suninitially had, that were pushing the envelope have moved on.
Getting Swing to the level it is today is no joke, and just because Sun has an idea of making developers and non-developers-alike create applications in a shorter time with all the whistles and bells with JavaFX is not enough reason for them to stop major development in Swing.
SwingX was a marvelous project for those that have put it to use in one way or the other, so getting to know that they killed it just like that is no good news. Even though I’ve been developing with Java for the past few years has not given me enough reason to embrace JavaFX. I’d rather go along with Flex than with JavaFX. Look out there at what companies/people are doing with Flex and you’d marvel at the speed, responsiveness and slickness of such applications, how many of such applications have we seen that has been done with JavaFX that we’ve seen? Most of the JavaFX apps that I personally have been seeing have been very dumb apps besides the ones created by those working closely with JavaFX and their evangelists.
The reality is that JavaFX is still being compiled to the same class file that normal .java files are being compiled to, so the problem is not that we need a scripting language to make us more productive, our cry has been about the things that need to be changed in the core which Sun seems to be doing nothing about right now. Well, the reality is that if Java won’t cut it anymore for people that have been putting it to use for many years now, they’d just have to move on to something better, though it might be painful. I just pray and hope that I took the right decision in embracing Java for the desktop when I did years ago.
Richard Bair has the answer on hos blog:
http://weblogs.java.net/blog/rbair/archive/2008/11/javafx_enterpri.html
We start to loss faith in Sun with Java on client site. With the new release of .NET on Linux and Mac OS, we’ll move our future developments to .NET environment.
The switch will be a painful process and require a lot of learning curve from us. However we just don’t see any light any more with Java on desktop.
Dont worry people, lot´s of time ahead of us, it won´t disappear overnight
I only have to say thank you to the Swing team and to Java. Client-side java is real and it’s now. We’ll keep on investing and producing high-end commercial Swing applications.
Stuck with Gridbag??!
1. Gridbag is actually one of the better layout managers if you’ve learnt how to use it.
2. How are you stuck? Layout managers are a perfect example where things can evolve and it’s easy to use another one instead without breaking existing code….
They shouldn’t remove it – is it causing a maintenance problem?
If they wanted they could create another tag in javadoc that rather than deprecated something, suggested alternatives for new learners – and if you created the javadocs with a certain flag on hid it ( which could also be picked by IDE autocomplete ), or could be used for deciding which chunks for the JRE to install.
A lot of this is documentation issue –
Deprecate for me should be
. we plan to remove it at sometime in the future… that’s why you’ve got compiler warnings
There is another option –
.. we think you should be using something else cos it’s better but we aren’t every going to remove this, so no compiler warnings.
Personally I think client side java has never been better – even the situation on Apple is much better than it has been historically – despite the much publicized wailing and gnashing of teeth.
I’d just wish people who for personal reasons need to move on to something ‘cooler’ wouldn’t expend so much effort at public self justification.
The JavaVM rocks – rock solid, rocket performance – this benefits all Java apps, including clients.
Core Java2D has seen much care and attention recently – benefits both Java Swing and JavaFX script apps.
[...] Script, puh! What a hype you might think, as I thought some weeks ago. I have some tears in my eyes while reading that Sun is not really improving good old Swing. Instead they push a lot of energy and money into [...]
Swing should be standalone. The public parts of AWT and Java2D should be Java’s sole interface to the native GUI system. Java2D is already accelerated, and one even have some amount of control of it with VolatileImage and friends like BufferStrategy, but some places it would be nice with more obvious access to and control of the underlying platform (I personally don’t like that “managed images” aren’t overt, e.g. some pure java implementation extending BufferedImage, utilizing VolatileImage). Obviously the APIs here would have to be extremely well written and well thought through – but even then, future evolution will have to be accounted for – possibly just accepting that a version 2 and 3 and 4 of this thin native access layer would at some point exist at the same time.
Had this been the case, Swing could be reworked to actually just be a pure standalone java library, without any hidden Sun magic at all (as it initially was). Even if one cannot at this point drop the backward compatibility for the current Swing (at least not for a couple of major java versions), one could simply “abandon it” – and make a refactored Swing2, fixing the problems, learing from mistakes, that NEVER got to be included in the JRE – applications would have to include it themselves (by using jarjar, possibly proguard approaches, only the necessary classed need be included). Swing1 could at some point become an actual optional element that itself needs download. And I would already look forward to the complete rewrite in Swing3 – or me and some friends would fork Swing2 into Swing2NG or something if we didn’t like the direction it was taking – thereby getting progressive dynamics into the development!
This seems very good. It is final, apparently committed to OpenJDK:
http://openjdk.java.net/projects/caciocavallo/
Actually, is seems pretty much everything this guy does is brilliant:
http://kennke.org/blog/
Btw, JavaFX must die. Fast. How stupid that was of Sun. Why not “fix java”, in particular on the client/desktop GUI and JVM installation/update side, before embarking on idiotic, random, completely new developments?
Cool, lets make Swing better – remove the GridBagLayout.
Advice swithc to .Net. They will make what You want. They switched GUI three times since Java started (Visual Basic, WinFroms and now Silverlight).
It is really cool.