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. My vision is one shared by numerous others, and in a brief discussion (via twitter no-less), a number of us enumerated what we believe a Swing 2.0 needs. The following list is a brief overview of what Swing 2.0 should be:
- 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. There is work in this direction already with the Swing-generics project, although progress is slow. Swing 2.0 should include this project instead of duplicating work.
- Support for enumerations where obvious. There are numerous places where public static final ints could be replaced by enumerations. This leads to a cleaner API.
- Support for varargs. Once again, there are places where varargs could be used to clean the API.
- Improved support for collection frameworks. That is, we should not still be requiring Vector lists, unless syncrhronization is absolutely necessary.
- Stricter enforcement of event dispatch thread (EDT) rules. Swing is slow (or so the saying goes). This is untrue, but is unfortunately the perception. This perception exists because 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. This may make developers unhappy, but the end result is better programs and happier users. It is worth it.
- Improved support for bean binding and validation. I won’t go so far as to say we need properties, largely because I don’t know enough to have an informed opinion, and I know that by saying we need properties Swing 2.0 instantly becomes far less possible without major Java language updates. But, I know that projects such as the JGoodies beans binding and validation tools are very useful, and make creating data-driven user interfaces far easier and rapid. It may make sense to incorporate these kinds of frameworks into Swing 2.0 to enable users to focus on the business logic, and not getting data to and from the user.
What you may note is missing is any mention of new components, new Look and Feels, etc. That is not my interest – in my opinion Swing 2.0 is 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.
What do you think? Do we need a Swing 2.0 that has the roughly the above features (make any suggestions you have). Is it too little too late for desktop Java (personally I think not, obviously)? Please, leave any comments or thoughts that you may have – let’s get the discussion started.
Hi
Some quick thoughts:
1- I suggest everyone take a look at: Thinlet, Pivot, Buoy, Foxtrot, Glazed Lists, et. al. to see what alternate takes on lightweight Java GUI frameworks, or solutions to Swing dev problems, are already available. Pivot in particular is a complete GUI toolkit which was started recently and is in active development. Buoy has some great ideas. You might just join one of those efforts.
2- As far as coding goes, you could save a lot of time by starting with an existing Swing codebase. There are three complete or mostly complete ones I know of as part of OpenJDK, GNU Classpath, and Apache Harmony. Just pull out the javax.swing.* packages, open in your editor, rename the top-level packages, and start hacking. If you keep a couple of Swing projects open in your IDE at the same time you could even refactor both Swing and the apps at the same time. Just choose a license you can live with.
3- I would try and contact long-time Swing developers (there are some like Jeanette on SwingX who started with Swing when it was in beta) and take an interest in their input and insight.
4- I think a good community goal is to make sure it’s fun to use. Take a look at the enthusiasm around, say, Processing and Groovy’s SwingBuilder. It’s a practical idea to support the business market, but if you can get hackers and hobbyists interested in playing with the APIs you’ll get free press, feedback, input, etc. Those folks will let you know with no hesitation when your APIs are getting complex, hard-to-use, etc. And when you hit a home run, they’ll be there to cheer you on.
Thanks for starting this discussion.
Patrick
@Patrick Wright: Thanks for your thoughtful comment. I am definitely trying to contact people who might be interested. If you know of anyone, please email them directly and refer them to this blog.
Cheers!
Hi all,
For me Swing is part of my daily job and I learned to love it and to hate it. I believe having an Swing 2.0 would be a wonderful thing.
There are a lot of interesting ideas here. Mikael Grev has already highlighted most of the severe problems with the current Swing implementation.
We develop now for 10 years a big Java application. It has 30000 classes and 4 million lines of code.
We started with Java 1.0 some decades ago. We kept it up do date all the time and currently it is migrated to Java 1.6 it uses Generics in all ways and makes good use of all modern Java APIs.
How did we manage it to keep the application alive for this long.
Refactoring! Even BIG refactoring.
So my advise is. Take Swing 1.0 and start refactoring. Even complete radical changes are possible with refactoring when done right. To change some APIs or to get rid of old components some times took 2 years and longer but someday you are finished.
Why not write from scratch? It is alluring. But is there only one guy around that can claim that he will do everything right straight from the beginning. Well start from scratch and plan a big Swing2.0 and in 5 years from now you will perhaps be finished and have a Swing 2.0 that will be better in some areas and some others will have problems as bad as the problems that you have now with Swing 1.0
So copy the current swing and start refactoring. Add methods and models with generics and make the old ones deprecated. Find all references to the deprecated methods and remove them one by one and you will have a Swing 1.0.1 Add Painter Support to all components and you will have an Swing 1.0.2, …
Just my insignificant opintion.
- Bernd
@Bernd Rosstauscher: Your opinion is just as significant as everyone elses! Your thoughts are much appreciated, and I tend to agree that refactoring would be much easier, in the sense that people will instantly see progress, and we can follow a more ‘release early, release often’ approach.
Personally, I love refactoring, especially major refactoring – it’s like breaking apart a puzzle and trying to put it back together again, but with the challenge of making the code better, cleaner, and less complicated/bloated.
I’m all for either Swing 2 approach, but my inclination is often shifting. Right now I agree that a refactor is better and faster than a rewrite.
Keep up the comments, now moreso especially because we are slowly getting the attention of people within Sun.
Cheers!
As a every day entreprise programmer i’ve take a look at JavaFX. My question to sun is : how to i deal with my legacy code ? how can i build entreprise level application without even basic standart component like Swing ?
FX respond to a need of multimedia for the multimedia client application it could not be a replacement for Swing until several months and only if it lead to an advanced framework which noboby now can even imagine.
The idea i got from Swing2 is a SwingX visually reach components framework based on the last Java grammar evolution. And said like this it perfectly feel the gap for every day job.
I do REALLY HOPE that some strong DECISION to START SWING2 will emerge from this thread.
Cheers !
Well, I don’t know much but I am busy learning JavaFX and I am learning about Swing indirectly so I can use it in JavaFX.
I suggest you figure out how to use JavaFX in Swing and you will make a lot of friends:-)
Starting from scratch seems too daunting and not many understand the internal of Swing well enough to make radical architectural change (though with the Swing team’s help, it is possible but now their focus seems to be JavaFX).
Just like Aberrant thought, Is it to possible to fork out the existing Swing and probably start from there like remove deprecated methods, standardised call, add additional classes, update it (like use ArrayList and generics in gui datamodel), improve it (adding MIGLayout as core, etc). Over the years I have improved certain classes in Swing that hopefully can be backported in “new Swing”. It is very likely to break binary compatibility.
Improving the Swing to such extent in OpenJDK seems impossible since Sun still wedge control over it ?
Well,
Swing2 is in development in some form
Richard Bair saying “new user interface control toolkit” in this JW article:
http://www.javaworld.com/javaworld/jw-01-2009/jw-01-client-side-roundtable.html
Hopefully it is in Java, NOT JavaFX and lessons learned
Cheers.
I love the idea of a swing2.0 that is separate from JavaFX. I’m a groovy guy myself, but I still see a need for a swing2.0.
I would love to see it built on glazedlists, my all time favorite java library.
I also agree that taking swing1.0 and going for the swing2.0 goals via refactoring is probably the best way to achieve anything.
My vote would be not to wait for properties in the java language.
I love all of Mr, Grev’s ideas except waiting on properties.
If we have to have properties, I’d rather have something we don’t have to wait for in the language, but use something someone was pushing on java.net a while ago where you don’t use String or Integer, but StringProperty and IntegerProperty and they have built in events and such. I know that’s likely to be controversial, though. But if we had that, we wouldn’t have to wait for properties in java.
it’s just that properties in java is such a great idea, but for some reason hasn’t made it so far, so I don’t see it making it at all.
I also like a lot of the ideas in JMatter, though I don’t know that they are applicable in swing2.0.
I also agree that manpower is a big issue. I don’t feel that I am all that much of an expert to be able to do much of the intricate coding, and it’s hard to find the time.
So, big thumbs up to Mr. Grev and swing2.0.
Regarding properties – I think Swing 2.0 can NOT be dependent on them – even if they are available in Java 7, still there are many good reasons to keep support for Java 5 (or at least 6).
+1 from me. It seems that by posting this, and by the response, you are now have the ball to organize this…
There is one point that I would be willing to work on: models. Most of them can be easily generified without really impacting that much on the rest of the API. For example, a ListModel can become a ListModel. Then we can have a series of model implementations that constructs models from collections. For example: ListModel CollectionsModel.createListModel(List list).
I am already forced to do things like these… and other people here have already complained about models too…
Oh well, it seems that the generified notation on my previous comment was lost…
I generally like most of the ideas presented so far, but I disagree with some of Mikael’s suggestions.
* I think Components should NOT be able to paint outside their bounds (drop shadows should be handled differently if you want them to extend beyond the component bounds. Just have a way for components to paint on another layer, where their bounds don’t apply.
* I think Components SHOULD be containers – e.g.: the idea that an editable combobox contains a text field and a button makes sense.
I think properties are needed if you are going to put in the effort to make a Swing 2 that is the time to get properties into the language.. rather than having another mismatch when they are added later. (Just like we have with collections framework and swing now. Or static final ints and no enums, etc.)
I want to give you a hint to: http://weblogs.java.net/blog/hansmuller/archive/ts-3492-final.pdf
Its not directly about swing 2.0 but about important thinks in the context. For inspirational purpose you should also give groovy+swingbuilder a try, its a breaze of fresh air.
I would suggest that there are too many layout managers in Java SE. For the average user this causes a great deal of confusion.
A new layout paradigm that allows the users to put components in limited number of ‘structured’ containers such columns, rows, grids, tabs and cards with proper specified alignments will simplify the Swing programming considerably. Imagine being able to do something like this
createRow(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)
createGrid(verticalAlignment, horizontalAlignment, twoDGUIObjectArray)
createColumn(verticalAlignment, horizontalAlignment, oneDGUIObjectArray)
where the arrays contain Swing Components or the aforementioned ‘structured’ containers.
This will be an order of magnitude improvement over the existing way of doing things, and make the concept of layout manager essentially irrelevant for the typical users, obviating the need for every tom, dick or harry to invent his own layout manager and proclaim it to be the best among the lot.
Of course such an approach has already been implemented, but Swing can do it too.
@Tom Corbin
Bean Properties might be the project you are thinking of.
https://bean-properties.dev.java.net/
I actually prefer the approach of using a well defined property interface to that of adding properties to the language. There are a few similar projects, but I think that one is the most developed.
The problem with using an enhanced definition of properties and beans is that tool support will lag. Nonetheless, it is worth doing. Jettisoning the inherited AWT methods have similar consequences that are even more drastic. The current level of AWT interoperability that Swing provides has long since ceased to be worth the API price it imposes.
+1googol for Swing 2.0.
Let me add my own todo list :
– pure Java2D default PLAF
– full support of alpha chanel (yes, I want to be able to do overlay in applet over a HTML page)
– default vector base plaf (nimbus)
– enhanced java control pannel (default LnF, properties configuration, etc)
– Editable list (“yes we can”)
– default Bean friendly/aware model
– tight integration with EJB : automagical link established whatever is the network condition (proxy, etc) security)
– default renderer for esasy SVG integration (design a SVG resource with two ID and $text and use if as button) : key feature to bring design
– enhanced HCIL event support (multitouch & all) : I am already on this one
– full CSS support for styling using class and ID=command
– more default component for usual things : DateSelector where art thou
– scene model
– animation engine
…
On the last points, I think lot can be “borrowed” to JavaFX …
If we’re starting from a clean sheet of paper, I’d want to see the class hierarchy flattened — no deep inheritance chains. It should be vastly more compositional (interface-based). Why should I have to inherit hundreds of methods in order to have a menu? (JMenu has 433 methods at last count.)
Don’t force me to subclass already-huge classes, or write wrapper classes, in order to do simple things. Give me some lighter weight alternatives to the big kludgy JMonsters. I don’t need all 433 methods of JMenu and its ancestors.
If you’re writing JavaScript, there is no way to subclass a JComponent and override a method in it (from a script), so those of us who use Rhino (or the embedded scripting features in Java 6) “in anger” are left no alternative but to … feel angry.
It might be good to have Swing Lite and a Swing Heavy that wraps the Lite (?) — but I still favor more compositionality and less inheritance as a motif for Swing.next.
Thanks! Great post. Great dialog.
Swing is great but there is a lot of work required even to do simple things. Rather than start with all the complicated cases how about starting with simple things that people do in every application:
* display dates (without using an external library)
* display currency
* display images (much more simply than now)
* tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc). Then the default model could be used in most cases.
People avoid Swing not because it doesn’t have enough power. They avoid it because it is too much work to do basic things (display an image requires understanding how painting works, instead it should be a single call on a component to place the image).
The problem with Swing is it was designed by very clever people in a hurry, which makes it slow for less clever people (think government or corporate developers) to develop things in a hurry. This is the real Achilles Heel of Swing as it is.
Swing 2.0 needs to be “As simple as possible, but no simpler”.
@Mike Reid: Thanks for your comments. I think the problem with any API is that you need to know all of it to be a power user. Swing perhaps complicates this by having a huge API (due to inheritance). In the case of displaying images, you can always put them into a JLabel.
To everyone commenting, thank you. Your support for the project, or your comments against the project, are all welcome and appreciated. We have succeeded in catching the attention of Sun – they should be getting a response back to us within the next day or two. I will post a new blog post then, and will post a comment into this post here so that anyone subscribing to comments is updated.
How Swing 2.0 continues next is a function of how Sun responds to our suggestion, so we must now wait until we hear from them. Despite this, please continue adding your suggestions to this blog post – it is certainly the best place to gather your thoughts on Swing 2.0 at this point in time!
Cheers!