With Sun's all-out support for its nascent JavaFX language and runtime, many Java UI developers started to wonder if existing shortcomings of the Swing APIs would ever be rectified. For example, this blog post on Artima questions if work on JavaFX was taking away resources from fixing Swing problems.
Swing is used by a large number of developers, and Sun has always maintained its commitment to improving Swing. However, to date, little has surfaced about Sun's concrete plans about Swing's future. Promoted by Jonathan Giles' recent blog post, Sun's Danny Coward recently penned an extensive update to Sun's Swing road map.
Giles writes that the need for an updated Swing API is shared by many developers:
I believe that there is a need for a proper Swing 2.0 which is not JavaFX-based, but a true, desktop focused, Java (the language)-based framework...
In my opinion Swing 2.0 [should be] a cleanup of the code beneath the existing Swing components. It would be ideal if Swing 2.0 could be API compatible with Swing 1.0, but I would not be adverse to Swing 2.0 becoming a separate Swing library in its own package (i.e. javax.swing2). This would allow for API cleanups, and repurposing of existing API method names.
Giles then summarizes the key features desired for a Swing 2.0 release, based on his discussions with other Swing developers:
Generics-based. No more should we put our objects into various Swing data models and components only to receive Object back. It should be possible to create swing data models and components with the data type specified...
Support for enumerations
Support for varargs.
Improved support for collection frameworks.
Stricter enforcement of event dispatch thread (EDT) rules... Developers don’t understand how to deal with the EDT. There exists code out there now that can enforce the rules surrounding the EDT by essentially throwing exceptions when components are handled off of the EDT, and when tasks take too long that should not be run on the EDT. By default, Swing 2.0 would enforce EDT checking, throwing all exceptions discovered.
Improved support for bean binding and validation.
In response to these ideas, Danny Coward, Sun's lead on upcoming Java SE releases, notes that:
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 of enterprise desktop applications...
So our focus has been shifting ... from filling out what were then major gaps in Swing as a UI toolkit, to making it easier to develop with the Swing, and to making the runtime deploy and perform better...
Coward describes the two steps that constitute Sun's road map for the next version of Swing:
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.
Also in JDK 7 we'd like to include other components such as JXLayer, the DatePicker, and CSS styling also...
Coward also discusses the possibility of using the Swing APIs from JavaFX, and why breaking backwards compatibility with existing Swing APIs is not in Sun's interest.
What would you like to see included in a Swing 2.0 release?
3. CSS-like skinning, instead of current LaF structure (too difficult to create a new or adapt a existing LaF), maybe evolving the Synth LaF
4. support floating-point coordinates and dimensions
5. drop the unified layout manager interface (which is too damn limited: a int, String or Object param?), maybe make panels layout themselves, or we could add components directly into the layout manager (which would add them to the container, but could attach any metadata needed, and could have a easy-to-use interface, like, fluent)
6. consider using a thread scheme like SWT's, instead of creating a background thread silently (I don't know the implications, but this would ease the use of the toolkit by scripts, for example)
7. maybe it could wait a little, for the closure support to be available? (well, this could take forever...)
8. it should be open source and used as a third-party library, not included into the JRE, or included as a extension package, so that it can evolve in parallel, without the need to wait for the 2~4 year release cycle of the whole runtime
Composed Focus support that doesn't suck. Css. Unforgivable that there is no real view in a supposed ViewModel toolkit.
For god's sake make things controller based. You know that shit that doesn't matter mostly, the JComponent? Wrap it in a getView(). Yes. Just like netbeans.
Also, don't be afraid to change things. If it doesn't fuck compatibility and require the users to download a old version. I "get" incremental evolution but there are thing that you just can't fix. I like there is one way to do things.
> Also, don't be afraid to change things. If it doesn't fuck > compatibility and require the users to download a old > version. I "get" incremental evolution but there are thing > that you just can't fix. I like there is one way to do > things.
If possible just "One" model for all components would be great. I have no idea if it is or not, actually but i think that Wicket does this.
1. Make the models a separate library. Models can be reused in non-gui applications as well.
2. make everything model-based. For example, widgets should not have an enabled property. 'Enabled' means that some functionality is allowed, and therefore the enabled property should be part of the 'command' object which invokes the necessary function.
3. Don't make it multi-threaded by default. Make the gui thread the main thread. If the users want to do long running tasks, let them do it, don't force it upon them.
4. use signals and slots instead of observables and observers. Signals and slots is a much more powerful mechanism.
5. reuse the default toolkits where possible. It's not that difficult to reuse win32 controls for example; it just takes a little bit of planning.
6. do not use layout managers and layout classes. Offer layout widgets. It's confusing to have a tree of layouts in parallel to a tree of widgets.
Throw exceptions (or at least do assertions) when something needs to be done in the EDT and is not.
This is *way* to tricky and there's no reason developers should have to hack this into Swing themselves. They're just guessing whereas the Swing development team knows exactly where such exceptions/assertions should be done -- and can do them correctly once and for all for all other developers.
What is wrong with JavaFX? Why not have JavaFX fill in a market/programming niche as a kind of Swing 2?
I'm fairly new to Java and I'm primarily interested in the script languages (mostly Groovy, and now JavaFX). My previous programming experience, going back to 1995, is mostly with script languages (starting with HyperTalk on Mac-only multimedia projects and then moving on to AppleScript, then Perl, then PHP, then Ruby).
Can someone offer a concise explanation of why JavaFX can not be made to fill in the space where Swing 2 would slot itself? In particular, those who, in the thread above, think it's acceptable if Swing 2 has an API that's incompatible with Swing 1 - what is your objection to JavaFX?
> Throw exceptions (or at least do assertions) when > something needs to be done in the EDT and is not. > > This is *way* to tricky and there's no reason developers > should have to hack this into Swing themselves. They're > just guessing whereas the Swing development team knows > exactly where such exceptions/assertions should be done -- > and can do them correctly once and for all for all other > developers.
If they were going to do that, why not just submit the call to the EDT instead of throwing an exception. Then the user wouldn't have to think about it at all.
Previous Topic
