Swing and JDK 7

Prompted by a vigorous discussion on Jonathan Giles blog about whether Sun is ready to do a 'Swing 2.0', its time to lay out where we (at Sun) are with Swing. So here it is.

Swing and Sun

Swing is really important to Sun. We have a large and vibrant group of developers who are developing and maintaining Swing GUI applications. Its APIs, components and underpinnings are critical to Java's future position in developing rich client applications of all kinds.

In contrast to the early years of hectic build out of Swing, we've slowed the growth of APIs over the last few years. This is largely because, despite gaps in the API set for some applications, compared with those early days (or with JavaFX today), the Swing APIs are broad enough to build most enterprise desktop applications. And that which is not there can most often be added with a third party library or component.

Building with Swing. Building on Swing

At the same time we've also seen a growing role for Swing, and its underlying graphics runtime, as a basis or inspiration for other RIA technologies. Such as our own JavaFX, which uses both graphics stack and many of the Swing components in its desktop profile, or such as Griffon, Thinlet, Pivot and LWUIT to name but a few.

So our focus has been shifting (starting well before the advent of JavaFX, even of Java SE 6) from filling out what were then major gaps in Swing as a UI toolkit, to making it easier to develop with Swing, and to making the runtime deploy and perform better. Progress on both counts are a benefit to Swing developers but also to other technologies that depend on Swing and its foundation.

Sun's priorities for Swing and JDK 7

To that end, the priorities for our effort between JDK 6 and JDK 7 are: first to make the runtime lighterweight (faster download, faster startup), better integrated into the browser, and with improved runtime performance. Some of this we have already delivered in Java SE 6u10, but there is more to come. And second to take a big swing (!) at reducing the amount of boilerplate code and conceptual complexity in a developing typical swing application with the Swing Application Framework in JDK 7.

We've also set things up in OpenJDK to make it easier for developers outside Sun to contribute to Swing, and we hope to help integrate some backwards compatible features created outside Sun into the JDK. We'll be working with the XRender pipline team to bring graphics acceleration to Java on Unix platforms. Also in JDK 7 we'd like to include other components such as JXLayer, the DatePicker, and CSS styling also. And perhaps other components or features, as mentioned in some of the comments in the thread, all such contributions depending on the usual constraints of quality of implementation, accompanying tests and of course, timing.

On a related note, some have mentioned a desire to use JavaFX features from Swing: we're interested in hearing what kind of Swing applications you are writing that might require JavaFX components to be embedded as we figure out the next releases.

Not ready for an incompatible revolution

Now, some of the discussion at Jonathan's blog reminded us of the many areas in the APIs that need updating: largely because of the advent of new Java language features and SE APIs that were added after the Swing APIs were created, that now provide much more convenient and reliable ways to manipulate Swing than were possible before. But we have a more conservative attitude towards breaking backwards compatibility than some of the commenters on the thread (and beyond): an attitude formed out of years of talking with developers and customers who depend on Swing. (As an aside, you may be curious as to the inherent design issues regarding the EDT). Now JDK 7 modularity will likely provide a neater way to move gracefully to some possible future backwards-incompatible version of the Swing APIs. But in terms of where we put our effort today, we don't think such an evolutionary cleanup, albeit useful and desirable, its enough reason to disrupt existing applications, tools, books, tutorials, courses and frameworks that are built with today's Swing.

Are you ?

But if what you want is revolution not evolution, if you would like to see bigger, more radical changes inside Swing, then please consider that you have all the source code for Swing together with the supporting infrastructure to create a project and broadcast its existence at OpenJDK.org.

It's why, in part, we set up OpenJDK: to make it easier for you to bring the next big RIA idea to life.


Thanks for the update Danny - pretty much what I expected. I understand why Sun has to do it this way - backwards compatibility has always been a big requirement for Sun and Java.

Thanks for taking the time out to consider our thoughts.
Jonathan Giles

Posted by Jonathan Giles on February 04, 2009 at 06:35 AM PST #

Can you clarify what will happen to Nimbus in Java 7? Will Nimbus remain in com.sun.\* packages, or will it move to something like javax.swing.nimbus.\* ?

Also, assuming it moves, will the com.sun.\* version vanish, or will both versions coexist for awhile?

And finally, how stable is current Nimbus? I mean, will string keys in NimbusDefaults continue to be supported in Java 7? Because right now, modifying UiDefaults tables and writing custom Painters is the only way to customize Nimbus, leading to code dependencies on com.sun.\* packages. I am very concerned that my code may break when Java 7 comes out.

Posted by Eric Burke on February 04, 2009 at 07:13 AM PST #

When is Java 6u10 and the enormous improvements it made for client Java in the broswer coming to OSX?

Posted by mike on February 04, 2009 at 09:07 AM PST #

One glaring deficiency is the absence of the implementation of at a minimum a triangle shading algorithm in Java2D: given the colors at the three vertices, paint the triangle by linearly interpolating the colors. Conceptually its a simple problem, but a JDK implementation that makes good use of the desktop's graphics hardware would be a challenge for an ordinary programmer and so a JDK implementation would be quite useful. Of course it would be nice to have an algorithm that applies to convex polygons, but that would just be gravy.

JOGL or Java3D come with too much complexity for this simple problem.

Posted by gregor on February 04, 2009 at 11:46 AM PST #

You asked about using JavaFX within Swing.

We have a large client/server application with a Swing/Web Start client. We are looking at developing an alternate client for a different group of users with JavaFX in an Applet. We will want to use some of the JavaFX screens developed in the Swing client. For this we will need to be able to put JavaFX panels in Swing (or even AWT) panels.

To dip our toe into the water I wanted to write a new About box using JavaFX. Unfortunately I couldn't even do this.

Posted by Larry Singer on February 04, 2009 at 12:18 PM PST #

On JavaFX within Swing;

Its one step to slowly introduce new technology in an existing application, e.g. a fancy about box, then to rewrite the application from scratch.

Having JavaFX within swing will IMHO be a major incentive for it's adoption. As you've just said yourself; evolution not revolution (migrate instead of rewrite).

Posted by Tom (tbee) on February 04, 2009 at 04:30 PM PST #

JavaFX within Swing?

I've been investigating whether or not it's worthwhile to create a charting component for JavaFX a la JFreeChart. It's a lot of work, but if it could be used within Swing too, then it would be easier to justify the effort.

Posted by Dave Gilbert on February 04, 2009 at 05:11 PM PST #

I am glad to hear that Swing is still considered at Sun. I can also understand that compatibility is handled on high priority.

It is only a few months ago, that I decided to develop in Java in the future and Swing (together with NetBeans Matisse GUI designer) was a pretty good reason for me.

Although there is a hype on RIA I still see plenty of good reasons for a "thick" desktop client. Many widely spread applications - even if transferring data through the internet) are still a "real" client (Firefox & Thunderbird, Skype, OpenOffice, FreeMind, iTunes - just to mention a few).

I also barely think that applications like SAP could run efficiently on a bare web or RIA basis.

Further RIA brings me in danger of browser crashes or hangups if an RIA produces infinite loops or memory leaks.

I am personally not that interested in "migrating Swing into JavaFX".

So please keep Swing(ing)!

Posted by Martin Wildam on February 04, 2009 at 09:39 PM PST #

You missed to talk about SwingJavaBuilder (http://code.google.com/p/javabuilders/wiki/JavaSwingBuilder), the best framework if you want to maximize your productivity (a very concise view with a amazing DSL layout based on Miglayout) in Java UI. Try it and you will adopt it.

Alexandre Navarro

Posted by Alexandre Navarro on February 04, 2009 at 09:43 PM PST #

Regarding JavaFX in Swing. Desktop Applications are becoming more "flashy" and are moving away from a common desktop look and feel. Think Skype, iTunes, or your fav. chat client. Clean layouts, transitions, and effects are starting to become standard in desktop applications. It would be great to be able to use JavaFX in Swing to retrofit and "jazz up" existing code. It could be as simple as wanting to "side in" a control rather than call x.setVisable(true). Although it's probably possible in swing with some messing around, being able to leverage JavaFX - being designed for this purpose - would be a big plus.

Posted by Chris D on February 04, 2009 at 09:52 PM PST #

I tested a few look and feels and there are some really nice ones (e.g. Substance, jgoodies or l2fprod). I like very much the substance and that is nice "enough".

Posted by Martin Wildam on February 04, 2009 at 10:21 PM PST #

Today's demand (trend?) for RIA applications and need for speed/effciency must be accomplished no matter RIA is offered through the Swing, JavaFX, JSF or combination of these technologies; it must be fast, light weight and easy to use.

IMHO, the way Sun handles backward compatibility is THE costly solution, at least for Sun. I hope Sun will use from what you learned from introduction of backward compatible Generics in to the Java.

If backward compatbility is THE requirement, I would suggest you to offer backward compatibility through a separate source code level migration, and not through the core Swing/JavaFX framework.

Posted by Mayur Patel on February 04, 2009 at 10:34 PM PST #

In reality I do not need backward compatibility from the current point of few because no real project out there yet in my case (very new to java).

However, I know very well from very bad past experiences that incompatibility produced by "normal" updates for components that are used in several other applications can be THE HELL when searching for reasons after something is broken due to the update.

Microsoft went the way in .NET by separating library versions (framework 1.0 - 2.0) into completely different runtimes. They did a complete separation here, but why couldn't this be done for just the Swing part of the Java runtime? - As improvement in modularity is planned there could be an additional swing2 library and one can decide whether to stay with the compatible older library or switch to newer?

Posted by Martin Wildam on February 04, 2009 at 11:06 PM PST #

That's a very good post summarizing the Sun's stand on Swing and the work that need to be done.

Third-party library is fine however some developers will prefer to use the standard core components given the choice as these components have been tested and work with core system like Nimbus etc, and core component support/help is plentiful in forum, book and tutorials.Just delegating the job to 3rd party library may also increase learning curve (library may use different terminology and concept).

"Also in JDK 7 we'd like to include other components such as JXLayer, the DatePicker, and CSS styling also."

Hopefully we get to use these in JDK 6 ASAP (JXDatePicker&JXLayer are available but not CSS styling ?) as JDK7 is still a long time away (I think that JDK7 release in Jan2010 is still pretty too optimistic goal given the amount of work still need to be done in midst of the downsizing of Sun)

One major Swing component that the developer will like to use ASAP is the JWebPane, and there seems to be very little news on it. Is it making any major progress ? Last time it indicates it is 70% completed (http://blogs.sun.com/thejavatutorials/entry/html_component) . Can this work be consider as main priority too ? Without this gem, JavaFX and Swing could not take advantage of the web cool stuff eg GoogleMap,

Posted by GeekyCoder on February 05, 2009 at 12:47 AM PST #

Thanks for this information about Suns position in this area. I absolutely agree that backward compatibility is a mayor requirement. As we move with our software always to the newest Java version, breaking compatibility would lead to a huge amount of work for us. On the other hand I also see the need for an API cleanup. I'm very curious about the modularity support that will be developed into the Java language. This will perhaps give us someday the opportunity to get an cleaned up Swing 2.0 as a module, coexisting with current Swing.
I also think that Sun is currently investing nearly nothing into Swing. All changes mentioned above are targeted at making JavaFX better and to fill some gaps in this area. Of course Swing is taking benefit out of this but only as a side effect. This is not appeasing all of my worries that Swing will get less and less support by Sun.
I believe it is to early to start a Swing 2.0 (without modularity in place) but it would be time to start a toy project to build a Swing 1.5 and see how things "could" be improved, to play around with API changes/improvements and learn some lessons.

Posted by Bernd Rosstauscher on February 05, 2009 at 02:55 AM PST #


Yes do we have the source code, but the existing source code is not decoupled at all, its tied to AWT, tied to native code, tied to Java2D.

First, we must do :
- java.awt component cleanup from native code (native code must go in platform specific toolkit or peer implementation at any cost)
- javax.swing API cleanup (no OS/system specific code, no Java2D/drawing code here, only inheritance from AWT, event, model, etc).
- javax.swing.plaf : All the Java2D stuff, any system specific swing code must go here

By the way you've forgot a key feature "svg based renderer". The problem is that we can not have the look of a button redefined by a designer in a easyway. By using a SVG base plaf on a button. The client properties would store the "SVG renderer file" reference, that would be passed to the plaf UI implementation. Doing so, I can ask a designer to create nice button in Illustrator and get it imported straight into an existing Swing application. In a way, this is almost what has been done for JavaFX. Just that they have reinvented the wheel instead of reusing existing paradigm : SVG.

Posted by bjb on February 05, 2009 at 05:46 AM PST #

Thank you for all softwars

Posted by hossein teymori on February 05, 2009 at 07:27 PM PST #


Glad to see these advancements in Swing.
For business applications, I really miss the modal internal frames, necessary in some cases. It's really hard to implement "by hand", and a standard implementation would be nice.


Posted by Edson Richter on February 05, 2009 at 09:58 PM PST #

Why doesn't Sun just do the same thing with Swing that Microsoft did with Windows Forms and WPF? i.e. Namely, leave Swing there for backwards compatibility, but, create a new cleaner more robust UI framework for building new apps. Why o why did Sun have to come up with a whole new language for JavaFX? I don't understand why they didn't just do the same thing that Adobe and Microsoft did with Flex and Silverlight/WPF. i.e. Why didn't they just introduce and XML format for defining UI components, but, still use Java for the backing code. I would like to see support for partial classes added to Java. Java is lagging behind C# a lot now. I would like to see things like properties and events added to Java like in C#. I don't know why Java is having such problems keeping up these days. I guess there are just too many vendors and they can't get things done. It is pretty sad. Also, why is there no mention of adding data binding to Swing? What is the status of Beans Data Binding? If Swing had good data binding support, it would make it a lot easier to use and more competitive with Flex and Silverlight.

Posted by Jon on February 06, 2009 at 02:10 AM PST #

Indeed, full ack that there could be simply a new component/library with cleaned up and with new features.

What I do not see is the need of properties and events. I don't have a problem with the getter and setter methods (offers the same flexibility) and there are listeners. So why make Java more complicated than needed? I would not like the language getting bloated with such things.

And I don't see Java lagging so much behind C#.

Regarding data binding: I had that in VB and I stopped using it because of several reasons. One was the separation of data retrieval and presentation (Think of three-tier applications for instance). Then it did not work well for all database types (there it was really horryful). So this is also something I don't miss and maybe many more so that's probably a reason why it is not there yet. On the other hand I think I have seen something like this in NetBeans while playing around with GUI design. Maybe this helps: http://netbeans.dzone.com/news/binding-jtable-swing-controls-

Posted by Martin Wildam on February 06, 2009 at 06:30 AM PST #

The biggest problem with Swing is not the architecture, it's the look. Sun should dedicate some time to creating a signature Java look that is modern and as iconic as the one created by Apple. Nimbus is not modern-looking. It is not acceptable that developers have to re-write everything if they want to create a reasonable-looking Java-based application.

Posted by Swinging on February 07, 2009 at 06:46 PM PST #

There are many different look and feels available - I found some that I found quite nice. However design is something that many people will find different. I don't like the Apple GUI design so much that I want everything adopted to it...

Posted by Martin Wildam on February 08, 2009 at 03:09 AM PST #

The biggest problem is performance of start up in JavaFX and JWS.
I hope, shell re-written core code of AWT and Swing. For example these are a lot of code in java.awt.Component. Such of them should re-written by C language, After all, local code the more the better

Posted by yitongLiu on February 09, 2009 at 10:06 AM PST #

I am not convinced that it always better to have local code. You get the dependencies of local dll components then. And I have the nose full of incompatibilities and crashes after Windows updates. I am very glad that in Swing a lot of widget rendering is done by Java itself.

Posted by Martin Wildam on February 09, 2009 at 09:52 PM PST #

The same as UI technology and run in specifical VM, why Flash is excellent than Swing and JavaFX? Can't learn the successful experience from AVM?

Posted by yitongLiu on February 10, 2009 at 10:07 AM PST #

The same as UI technology and run in specifical VM, why Flash is excellence than Swing&JavaFX?
Cann't learn from some successful experience from AVM?

Posted by yitongLiu on February 10, 2009 at 10:14 AM PST #

@Martin Wildam
I agree that a lot of widget rendering is done by Java itself.
But I think that Swing needs to enhance its performance, especially its start-up with JavaFX and JWS. I find that some basic component is lengthily like java.awt.Component. So some of work should handed over to local code to realize as possibile, not the whole.
As you said that incompatibilities, really? QT is a good case.

Posted by yitongLiu on February 10, 2009 at 10:36 AM PST #

One of Java's major focus is platform independence and this should be kept on high priority!

On Windows the more you implement natively the more you increase your dependencies from system libraries. I had different cases, from APIs changing their behaviour to suddenly get affected by additional dependencies. Library and dependency management under Windows is not so well handles as you might have experienced on other OS. I love Linux for the (better) dependency management.

One of the reasons I have chosen Java lately for new projects was the fact that I want to save me from installed-to-death workstations. On the last rollout on 80 PCs of different software products I had problems on about 10 because of whatever dll-combination was not correctly installed (replaced correctly at reboot, registered or whatever). I love it going back to the early 90's where I could copy a bunch of files to a directory, start it and that's all to get the software up and running. Deployment under Windows gets horryful, if you use too much external components that are not bundled into your executable.

Posted by Martin Wildam on February 10, 2009 at 03:22 PM PST #

Can anybody say something about the state of Swing Application Framework? Will it change from the version 1.03 (which is shipped with NetBeans), when it will be ready and stable, and is there some up-to-date documentation (apart from Javadoc) available?

I adore Java and Swing for their platform independence, but I'm worried about starting a largish project which would use SAF - if it changes, then I'm in trouble.

Posted by mad-j on February 10, 2009 at 08:32 PM PST #

What about first-class rendering of HTML inside of Swing components. Really embarrassing that Swing can't do this well.

Posted by jj on February 10, 2009 at 10:54 PM PST #

Whether or not will have larger performance increase about swing/Java2D when JDK7 release?

Posted by swinger on February 10, 2009 at 11:40 PM PST #

having spent my 3 years career on building swing applications and really enjoying it, I hate to admit it but swing is dead and after leaving my fist company I found many difficulties for getting another job because job offers are all about JEE technologies. So goodbye swing
thank you sun for letting swing down : half backed frameworks : validation, binding , modularity ...
that said, I think siwng is one of the most powerful gui frameworks once learned : see what guys like romain and chet can do.
the major features that are missing are good validation and binding solutions

Posted by komando on February 13, 2009 at 07:13 AM PST #

@komando: I think this thread has gone on way too long, but regardless, I believe you are mistaken. Swing is by no means dead - as you note it is a very good API, and therefore as long as it is not removed from future JDKs, it is still very much alive. Java 6 update 10 had a number of improvements for Swing, as will Java 7.

To say that Swing is dead and that you can't find employment simply sounds a little lazy to me. I have had no trouble staying employed as a Swing developer, and it is still sought-after.

There are validation and binding solutions available out there - I have had a lot of success using the JGoodies libraries, which are also free. I would suggest casting your net a little wider next time you try to develop Swing solutions - there are many great libraries out there that are designed to improve the swing developers experience.


Posted by Jonathan Giles on February 13, 2009 at 07:20 AM PST #

@komando:I believe you are mistaken.If you job offers are all about JEE technologies you may be right, but the client of JavaEE not be HTML/JavaScript only, is can be Flash which very like swing, and JavaFX base on swing is also.
Swing is never dead in the future a long time

Posted by swinger on February 13, 2009 at 11:09 AM PST #

Hi Danny,

, at least good to hear, that Swing is not completely dead. Like Bernd I would love to see at least a Swing 1.5 with a cleaned up API and maybe use of generics, but Java-CSS and Swing Application Framework is far better than nothing.

Speaking of Swing Application Framework, there seems to be not that much activity from the sun side lately. Does inclusion of SAF into JDK 7 mean that this will change?

Additionally: Are there plans for a few well documented more-than-hello-world examples that will help to teach newcomers how to develop Swing applications right?

Best regards,

Posted by Sebastian on February 14, 2009 at 09:10 PM PST #

yes jgoodies suite is very nice: validation, binding, the formlayout is a masterpiece
unfotunately these are not standard solutions and I would like to see a common solution approved
see the outstanding swingx framework which primary goal was to extend swing and "maybe one day" we see it
in the jdk. now this is cleary no gonna happen.
Also, I would be grateful if you send me some links of cool swing libraries even though I am full time "j2ee developer now" but my heart is still swinging :)

swing Application Framewrok is very nice and it is good to hear that it is gonna be part of jdk7
It is suitable for middle sized applications but don't you think that when developing
a complex solution, the SAF shows quickly many missing features. I mean that what is
needed in this case is a plugin architecture like the one of eclipse and netbeans plateform.
And, I always wondered why Netbeans plateform is not based on OSGI since it is older and
has proved its efficiency ? What do you think ?

Posted by komando on February 16, 2009 at 05:11 AM PST #

For making simple applications simple, nothing beats SwingJavaBuilder (as mentioned above) -- it represents the UI with a declarative, compact YAML file (much nicer than the xml solutions I've used), handling layouts nicely (MigLayout), associating listeners with methods directly, simplifies background threads, validation, and data binding. Very usable in the 0.3 version. Not an entire application framework, but definitely worth a look for inspiration if nothing else.

The relationship of Java Application Framework and NetBeans Platform and their future trouble me. We need a good application framework -- where is it?

Posted by Fred Swartz on February 23, 2009 at 12:54 PM PST #


You are right, I am not yet sure how good swing will scale to large scale applications. However I expect that a reasonable number of Swing projects is actually mid-size. Furthermore, I hope (but did not look deeper into that issue) that SAF in its full bloom will also allow for integration into larger frameworks/applications, so that e.g. Swing portals can be built with each "portlet" using features of SAF (e.g. background tasks).

Posted by Sebastian on February 27, 2009 at 05:40 PM PST #

The important issues to address is not about updating legacy code in Swing. Backward compatibility is really important. The important stuff for my company is
- modernize cross platform look and feel (check the flex l&f)
- higher level API (Eclipse inspired, modulized, customizable with persistent state and stuff, No need to reinvent the wheel each time you will make a complete product).
- integration with modern medias (Huge illustrator documents, with no need to turn everything into Java objects) Movies, better integration of 3D.
- lightweight embeddable native webbrowser component.

To reconquer the Web Java needs the following improvements.

- Startup time minimized to be able to compete with flash. If that requires a redesign of jar+class file system then be it. Prelinking of modules perhaps.

Posted by Erik Martino on March 01, 2009 at 06:26 PM PST #

.. and how about a TreeTable component? How about a feature rich Table that really doesn't need much tweaking to make it usable in enterprise? Features like filtering, multi-column sorting, etc...

Look at your own SwingX! There are still lot to do there. Just an example: On the paper, JXTree and JXTreeTable are supposed to have filtering but look at their code! They're simply commented out! RTL support is horrible. JXTreeTable does not even work in such environments. When will we see these components in a descent stage and ready to be integrated with core Swing?

Sometimes I really wonder, has it been really hard for a company like Sun to assign some reasonable resources to develop some descent components? Components that have been present for years on other GUI platforms? Look at the web technologies!! Sometimes they have a much more complete component set (both on quantity, and being feature rich) than Swing, which its primary goal is on desktop and MUST provide such components.

How about built-in validation, error/warning reporting and data binding support? There are many projects out there, like Spring-RCP(Desktop) and Eclipse-Platform, which are having these features more or less in their own ways!

There are lots of features which may be injected into core Swing to make the life much easier. And many of these could have been developed after 2001-2002 after when Swing had landed on core and was more or less stable after a couple of minor/major releases of J2SE. We're on 2009, and still discussing these basic needs for any enterprise applications one more time. And this time to be released on 2010, although I doubt we'll get a descent Swing then with majority of the features I've mentioned in my comment...

A depressed Swing developer, developing since old Swing v0.7 (before getting integrated into the core!)

Posted by Armond Avanes on March 02, 2009 at 03:49 PM PST #

about advancements in swing.

Posted by Abhishek Gowlikar on March 02, 2009 at 08:32 PM PST #

I want advancement like wathcing movie in a panel onclick button. like in future is it possible in future.

Posted by Abhishek Gowlikar on March 02, 2009 at 08:34 PM PST #

(1) JWebPane is quite important to be part of JDK 7, and should be available ASAP.

I hope one would be able to include Swing components with HTML components rendered by WebKit into the same page (a "slightly" modified WebKit to call Swing layer for rendering embedded Swing components); I hope proposed CSS styling is here for that goal. It would give a great Swing/HTML integration and Swing would take benefit from HTML as a DSL.

(2) The previous point (1) would be inline with what "I" have called "Swing browsers", see my post "Swing browsers - other interesting DSL Swing projects to follow" http://www.jroller.com/dmdevito/entry/swing_browsers_other_interesting_dsl

There is here an opportunity to revivify Swing (an HTML flavor as a Swing DSL for simplifying Swing programming).

(3) Following that idea of DSL, another option might be to propose a subset of JavaFX for Swing programming (here, JavaFX = Swing DSL), see my post "Proposing a Swing DSL from JavaFX ?" http://www.jroller.com/dmdevito/entry/proposing_a_swing_dsl_from

(4) About Swing (standard) framework, there is also an opportunity from JSR-299. Indeed, JSR-299 includes pieces that could be useful for Swing, like an event bus. See (again) one of my posts called "Seam is a kind of a Java application bus (somewhat similar to CORBA)" http://www.jroller.com/dmdevito/entry/seam_is_a_kind_of

Conclusion: no need to abandon Swing, but IMHO, efforts are needed and they could bring a good ROI if carefully choosen.

Posted by Dominique De Vito on March 02, 2009 at 09:16 PM PST #


Posted by ad on March 05, 2009 at 03:29 PM PST #


Posted by ad on March 05, 2009 at 03:30 PM PST #

please download me JDK7

Posted by hossein teymori on March 08, 2009 at 06:37 AM PDT #

Nimbus Look and Feel is added to JDK7, JXLayer is in progress



Posted by Alexander Potochkin on May 04, 2009 at 01:47 AM PDT #

Concerning embedding JavaFX into Swing,

I think Swing desperately needs a cross-platform media player because JMF (Java Media Framework) has been very difficult to work with and fails in comparison to JavaFX's JMC (Java Media Components). If JMC can be included in Swing or if a JavaFX scene that has the JMC media player could be embedded into a Swing panel, that would solve my problems.

Posted by RhinoGuy on December 03, 2009 at 11:49 PM PST #

come on jdk7

Posted by baojian on December 04, 2009 at 04:29 PM PST #

I've been programming Swing professionally since 2001 and apart from performance improvements, not much has actually changed. I've been coding with Eclipse RCP/SWT/JFace recently and while quirky plus rough around the edges, I find this more progressive than Swing - databinding, validation, sorting, filtering built into tree and table etc. I've also been toying around with the very impressive QTJambi - much richer and powerful set of widgets.

Swing is still very flexible and 3rd party support is substantial but unless Sun/Oracle stop treating it like an unloved step child, its all the way downhill from here I'm afraid. JavaFX is just the wrong move IMHO.

Posted by Tochukwu on January 26, 2010 at 12:46 AM PST #

As far as I got notice (read in other news channels) QTJambi is also not developed any more). There is databinding in Swing also as far as I have seen in NetBeans IDE.

As Swing is drawing the widgets itself there are much more widgets available as far as I noticed.

I find Swing really cool and so far I don't miss anything. The table widget is soooo powerful - but therefore also a little complicated for simple needs but I worked around it building my own flexible model. - Model-View principle is also there in Swing.

But my Swing experience on Eclipse was awful. One big reason for switching to NetBeans was the way better swing development there.

Also in my opinion I would rather liked to see more focus on Swing than on JavaFX - however, as I mentioned I am not really missing something yet.

Posted by Martin Wildam on January 26, 2010 at 03:28 AM PST #

I am very much looking forward to JWebPane. I come from a server-side background and as I have developed client applications, I have found so many usages for an integrated web browser. When you add embedded jetty and derby db, you can easily have a distributable web application. I hope JWebPane will be coming soon, and preferably with a version compatible with Java 6.

In the mean time I'm using MozSwing, which works quite nice, minus the 64 bit support.

Posted by Mike Bushman on February 16, 2010 at 08:27 AM PST #


open your eyes: with JWebPane (with Swing integrated as planned from the origin), SUN/Oracle has a good chance to define a Adobe AIR alternative solution, to bring more Java, and JavaFX also, on the client-side.

So, please release soon JWebPane, thanks.

Posted by Dominique De Vito on February 16, 2010 at 01:24 PM PST #

i am impatiently waiting for JWebPane. release it soon.

Posted by saira on June 30, 2010 at 01:44 AM PDT #

I realy look forward to see java Swing easier to develop and the runtime deployment and performance is better

Posted by Alan Mehio on July 01, 2010 at 08:11 PM PDT #

waiting for JWebPane too - i wish they would put the work that was done on something like swingx etc... have some amazing apps that could be built if we had JWebPane as demoed... What is terrible is they haven't come out and said anything official about it - all resources seem to have been either moved to JavaFX or have left Sun/Oracle -

Posted by aloleary on July 03, 2010 at 04:51 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

A blog all about Java in all its flavors on all client platforms from smartcards to desktops and everything inbetween.


« February 2017