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.
Although I agree 100% with the spirit of this post (and most of the comments,) I think there is another aspect that we have not considered. Can Sun afford to work on Swing 2.0? We all know that last week a lot of people were laid off, and some of them from Desktop Java. Sun’s stock has gone down in price big time. Even if Sun has all the good intentions to create Swing 2.0, I doubt it has the resources to do so.
IMHO, there is more than one aspect in Swing 2.0. First, the technical details (generics, enums, etc.) Second, backwards compatibility (which may be solved with javax.swing2 and Jigsaw.) And third, money.
I think it would be more likely that Swing 2.0 comes from the community than from Sun. I don’t know if Java’s license would allow this. I don’t know what is really Open Source and what isn’t.
Does it make sense? Or am I too pessimistic?
Regards,
-Alex
I’m all up for simplification, i think a builder/DSL might be interesting in this regard, not necessarily creating new component classes. If the latter was the way to go, not extending JComponent will obviously simplify things, a good thing in the long run i’d say, but a hard goal in order to cover the whole toolkit. (IIRC ken orr has this approach for his mac widgets for java)
A way to skin, or draw components in a visual tool, for instance SVG support not just for icons, but for lnfs and ui handlers. Painters are good, but i believe it would be nice to support artwork coming from designer over pure java2d code that’d need to be translated from comps. Either that or releasing the nimbus designer tool which generates java2d. I think it would ultimately lead to nicer looking components “easily”.
I also like properties/binding, but as API, not language changes (while potentially waiting for them in 2012 for java 8): maybe similar to bean-properties or pulpcore’s properties.
Which of course leads us to animations/transitions which is a must have in my book. So here, either the properties or the swing 2 api would support an easy way to animate things.
I’d like a way to support different input methods not only a mouse and keyboard, to easily do multitouch, bimanual or multimodal interactions, or games really, even though that’s less interesting for business. Maybe jxinput would be enough, i never really checked.
In the same vein, I’d also wish the rendering process would be split from the event dispatch if possible, or more generically a way to get 60fps consistently for the next gen & animated UIs.
I might say while i’m not a fan of javafx script, i really like scenario (the scenegraph underlying the javafx platform): not its API per se, but because it’s a part of how i’d naturally build UIs, so a lot of what i’d like is split between swing 1, the swing 2 features described here, and scenario.
Wow, a lot more posts since I left last night. I think the number one issue that needs a vote right now is the answer to the question how do we get started on a Swing 2.0? The general options appear to include starting from scratch (with wrapping of Swing where applicable), and basing Swing 2.0 on top of Swing with major cleanups to the existing Swing API.
There will never be a full consensus I’m sure, but it has been (and will continue to be) an interesting discussion. For what it’s worth, I’m not sure which side of the fence I sit on: I expect the simple approach is to rework Swing 1.0, but perhaps the better approach is to start from scratch and try to maintain a Swing-like API.
@Alex Ruiz: I would be highly surprised that this discussion lead to anything from Sun. I would be more inclined to believe that this be a community effort that may one day be accepted by Sun, but realistically probably not
Regardless, we aren’t cutting code yet, we still have a lot of discussion to do. We have to be understanding of the scope of a Swing 2.0 project, and so whilst a number of points raised in comments are great, many just won’t be feasible. We don’t want to be stuck chasing a dream, we want a usable, friendly, clean, powerful, Swing-like API.
Well that brings up the question “What is Swing?”. If Swing is the current code, then well, that has all been released under GLP+CPE so one could fork it and move forward. If it’s an ideology or way of approaching ui development then that’s harder to quantify. I think a lot is possible with a fork.
@Aberrant: I tend to agree – I think everyone agrees that a Swing 2.0 uses Swing 1.0 in some capacity. There is too much good quality code in there to ignore it. Whether components are extended from JComponent or not, there is still a lot of code in Swing that can be reused.
Consistent veto mechanism. JTable, JTree, JList, JTabbedPane, and others all have different APIs when you want to veto a proposed selection change.
@Eric Burke: Good thinking! That is a definite in my opinion.
Is there a possibility to use the JavaFX API without this strange syntax? Just pure Java?
@Ivan: unfortunately I can’t answer that question. But I agree, my interest is in using the Java language rather than what I consider a relatively strange JavaFX language. In addition to this, I would rather use a Swing-like programming approach (with the API being as similar as possible to Swing) rather than a brand new API. So, my vision is simple: Swing, better.
I agree with everything here except the addition of Properties at the language level. Existing property support can survive refactoring – it just requires a bit of IDE smarts. This does work with JSP pages for example.
There is no good convention for properties at the language level, they can mask performance deficits in code, and they reduce readability. Grab any blop of C# code and tell me what it does without looking at other parts of the code.
Let’s not make the same mistakes Microsoft made with C#.
@Dan Howard: I tend to agree – properties are not part of my vision for a Swing 2.0. I am quite happy with getters/setters for now. I believe considerable improvements can be had in a Swing derivative without the need for properties.
Should properties come along externally due to Java 7, 8, n-1 or n, then certainly, a Swing 2.0 should make be upgraded and cleaned up to make use of this. This is the problem with Swing – this did not happen when it had the chance, and the API has become too much.
There are lots of things I would like to improve in Swing, and Swing 2.0 (with a clean API) may be a good way to go about it.
I would also love to throw away the existing code implemented with Swing, but this is not an option after many person years of work. We would need a way to implement new functionality with Swing 2.0 while allowing existing functionality to continue running. We would therefore need a way to embed Swing 2.0 in our existing Swing application. (This is something JavaFX has so far failed to deliver.)
One method of doing this is to maintain backward compatibility, but I think this comes with a large cost. Another way is to build an adapter that allows Swing 2.0 components to run inside Swing containers.
There should also be the ability to embed Swing/AWT/JavaFX/SWT components in Swing 2.0 for maximum flexibility.
@Larry Singer: I agree – I think some form of wrapping is important to allow some form of reuse.
Unfortunately, from the discussions I’ve had with people regarding Swing 2.0, the real issue is that with such a (currently) hugely scoped project, it would be difficult to develop a solution that can make it all the way through to being truly usable without some form of funding. I am trying to have some discussions around this, but I’m just a guy in New Zealand – it’s really up to everyone out there reading this to push for a Swing 2.0.
+1
I’m only not sure about collections. Vectors should go, but should it be replaced by List etc. in API? I will be happy if we could use only proper interfaces as Model not collections. Maybe default implementation should accept new collections, but something like new JList(List list) should not be allowed in my opinion.
JavaFX is not Swing 2.0 but I believe this was marketing decision not technical one. When I was reading about F3 it was very much said what it will be better way to build swing application. Sun just changed mind in one point, maybe they should again.
swing 2 must be a modern api, tailored for the future : shouldn’t swing be based on a GL binding (JOGL or LWGL) to be able to have 3D effects ?
@Jonathan how do you think, is it possible that OpenJDK guys will be interested in swing2?
@Aekold: That is possible I guess, but I think at the moment we need to just keep discussing what a Swing 2 means to people. I’m about to start up a forum so that discussions can be a bit easier. I’ll make a new post once I do.
“I’m not a JavaFX person yet, simply because my day job is fully Swing, and it will be for the foreseeable future. For this reason, Swing 2.0 is what I need, not JavaFX.”
That is basically a non-reason. You don’t want it because your employer doesn’t want it for some unnamed reason…
JavaFX isn’t perfect and it’s possible that a revised Swing could potentially be a better fit for certain applications.
However JavaFX really has a lot of advantages, it’s a very serious contender for building rich-client desktop apps or plugin-based web apps, and when proposing a new version of Swing, you really need to adress it at a little more depth than “just because”.
@Mass: Thanks for your comment – I’m open to people disagreeing with me
To clarify: when I say my day job is fully Swing, that is because I am a full time developer who chooses to program in Swing. I am CTO of a software company, and so I choose Swing based on the fact it has been available for the life of my software, that the people who develop the software are skilled in it, and that Swing has never let the software down. Also, any outside work that I do I inherently choose Swing, because I know it so well and it works. Therefore, your second paragraph is moot – I don’t choose Swing “just because”, I choose it because it works, is powerful, and I have invested a lot of time to know it well. Throwing that away to instead use JavaFX just doesn’t make sense to me.
The feeling from the feedback I am hearing is that many people are in the same boat – they really like Swing, and to some degree don’t want to lose that when moving over to JavaFX. They feel like moving to JavaFX means that they have to throw the baby out with the bath water, and it doesn’t compute
At the end of the day, I want a cleaner Swing-like API, not a completely new one. That is my reason for a Swing 2.0 and not using JavaFX.
My daytime job is 80% swing. But I’m in doubt between JavaFX and Swing. User interfaces have become more fancy and Swing is not the best platform to add that too.
I’ve build an a.o. “apple menu” in Swing myself and know it is not the most practical frame to do animation in and the animations are not extremely smooth. So JavaFX certainly has merits when it comes to fancy GUIs.
I also have done some flash, so I converted a screen I wrote to JavaFX and was very pleased with the code-first approach. So JavaFX has some plusses on Flash.
But for normal administrative forms the JFX animation is overkill. So JavaFX as Swing replacement stands-or-falls with how well they will be supporting Swing alike coding. As it stands now, it is not sufficient.
However, the problem of learning a new syntax is not what is holding me back from JavaFX; it simply is not a replacement yet. But the syntax would never be a reason not to switch. We in the software business continuously have to learn new things. It took me quite some time to get the feel for JGoodies binding, more than the JFX syntax. As soon as you are at the point of “I’m comfy here, I don’t want anything new”, then you’re on the dangerous side of the hill IMHO.
So ATM JavaFX is not a replacement for Swing. 1.1 or 2.0 maybe, but who knows. And when will it arrive? Swing 1.0 always has me working around shortcomings because of its legacy. So if people are willing to rethink the basic Swing framework and write new components, I’m in and contribute some myself.
But I would very very much advise anyone to take one day and at least try JavaFX. It is not wise to form an opinion without having tried it.
+1 for swing, from me to!
@Tbee: Absolutely. I tend to think Swing is the right API for programming enterprise software, which is where my mindset is. I like nice-looking swing applications, but I’m not looking for inconsistent, animated, ‘designed’ user interfaces as much as I want a nice, enterprise look, with a cleaner API underneath to make development easier and less error prone.
As a side note, Thierry Lefort has taken the opposite point of view to the one taken on this blog, and you can see this here: http://www.jroller.com/Thierry/entry/as_a_swing_developer_i
Cheers,
Jonathan
Showering always is a good way to gather one’s thoughts.
Do we really want to invest our time and effort into a framework that is compatible with Swing (just like JavaFX), has a better painting logic (just like JavaFX), supports binding out of the box (just like JavaFX), and preferably does make properties and actions/events easier (just like JavaFX)… but is -in fact- competing with JavaFX to become the new Java GUI toolkit?
My beef with Swing, and the point that I was trying to push (hard
), is that the core is ok, but all the components need to be rethought and rewritten with user friendlyness in mind. So I wanted a new clean shiny J2Component and start from there. I’m leaning towards JavaFX CustomNode to be that new component…
If you want to know what needs fixed most in Swing, you need to survey the other Java GUI Toolkits. Buoy has a good analysis of Swing’s problems.
http://buoy.sourceforge.net/AboutBuoy.html
The hard question that isn’t being addressed is who will do the coding. I would love to see a Swing 2.0 that ditches JComponent. Without doing that, you won’t be able to address most of the basic flaws.
With limited resources, however, I think a much more reasonable strategy is to identify existing projects based on Swing (Spin, SwingX, GlazedLists, EventBus, BeanProperties, etc…) and consolidate them into a tested, documented, and supported whole.
Actually, just a well organized catalog of existing Swing extensions would be useful. Add descriptions, comparisons, and other useful meta data and it would be even better.
@Curt Cox: I agree – there is a huge amount of support I feel for a Swing 2 that cleans up Swing, but everyone is busy with their own projects to be able to focus on it. As I mentioned earlier, and as others have mentioned to me, it is a project that really needs a few talented API designers who know Swing well to sit down and plan the improvements.
I agree regarding pulling together lots of other projects, but the end result will still be based on the current Swing API. Making a list of their functionality and availability would be a nice first step however.
Just a quick update, Danny Coward has a blog at Sun called The Planetarium. He has posted a quick blog post acknowledging this discussion here. Danny Coward is a big name within Sun when it comes to JavaSE.
I use Swing and really like it. I don’t think its all that tough to learn though there are some things that could be easier. Alot of the items that are being mentioned sound great, but I do really think that we do need more components and themes/skins/LnFs built in. Sun should live up to its commitment to Java.net and leverage the great work by folks like Kiril and Romain and many many others and throws its weight (programmers, resources, etc) to get their stuff into Swing 2.0. It should also look look at and glean the various Ajax toolkits out there and understand that if it really wants Swing to be the UI toolkit of choice, it really does have to compete against all the ‘pretty’ stuff out there. But that’s just my 2.0 cents.