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.
@Jemsquash
I did that in my application a few years back, as the solution to the EDT problem, even considered using AspectJ to do that for everything javax.swing.
However I ran into unexpected behavior, can’t remember what exactly. Then I switched to using invoke later, again unexpected behavior (setText had not set the text – yet). Did manager to fix that with a second variable holding the value, but ended up installing the EDT checker and really resolving the issue.
All this may very well have happened because of other faults in my code, so the solution may work. As said; AspectJ can solve a boat load at once.
@Jonathan: yes, there would be some overhead but my point is that this overhead mostly already exists! Lot (most?) of Swing developers is already using “invoke*” or have to bypass it somehow (send “messages” to EDT).
So why not just make our daily development easier? And if creating new Runnable shows to be the bottleneck (which I don’t think so – just a feeling, no hard data!) then we can change Swing 2.0 internals to be more effective – while still keeeping API!
@Abraxis,
I tried something similar to what you suggested (EDT access in setters) and performance was horrible. Once we consolidated many actions in a single call (or Runnable) in the EDT, performance was not only great, it was faster than not using the EDT at all.
My point is that using Runnables in the EDT do not imply performance penalties if we use them *correctly*.
-Alex
@Abraxis,
I re-read your last comment. If the overhead you talked about is the overhead for the developer to deal with a cumbersome API, yes! I agree with you. Simplifying EDT access (API-wise) is a tough problem to solve, IMHO, and without closures in the Java language even tougher (my intention is not to discuss if Java should have closures or not.)
-Alex
@Alex Ruiz: EXACTLY – “using Runnables… correctly”. Let’s face it – there are many developers who just does not care about anything else then if the code compiles and does +- what it should
Can’t we somehow make Swing more intelligent so you don’t have to think about EDT? Just an idea without too many deep thinking – if bundling more changes into one EDT call dramatically improves performance, then why not let Swing to have “change queue”, put required changes in this queue and once a while (100ms) process whole queue? (of course it’s very rough idea, implementation would have to very different
)
Again – my main point is to allow developers to call label.setText(“Hello”) from any thread.
@CurtCox
That was exactly what I was thinking about, only half remembering.
It’s a very interesting project, though I doubt any one else would use it. It looks very powerful, though.
I’m betting sun won’t help – I don’t think they have the manpower or interest. In fact, I’m guessing they’ll want to discourage this work by making it hard to keep up with swing1.0 improvements.
But I guess we can only wait and see.
My preferred way of handling Swing 2.0 is to start with Swing 1.0 and start doing refactoring. I think we’ll get the most bang for the buck and while we wouldn’t be 100% backwards compatible, we’d maintain the most backwards compatibility this way and lower the learning curve.
I do have to admit that Pivot (and others) sound great, I’d rather incorporate their ideas into a swing 1.0 refactoring.
Just an update: Danny has posted his thoughts on Swing 2.0 on his blog here: http://blogs.sun.com/theplanetarium/
It’s pretty much as expected – they need to be conservative so an incompatible Swing 2.0 is not something they can do. They do encourage other people to do a Swing 2.0 externally however, given that all source code is available.
What are your thoughts?
I haven’t read all this thread yet but I just thought of something that might make this thread keep going MUCH longer.
For swing2 why not drop the layout managers and follow the MS way of using containers with relative layout.
I would love that – I could never get my head around layout managers.
Not to be an ass, but this conversation sounds more and more like it’s being run by a bunch of amateurs. A few of the suggestions that have been made make little sense yet no one called them on it. I also get the feeling that there isn’t a single senior API designer here.
Yes, we need Swing 2.0, but there is little sense working on it without some very senior developers leading this effort. Good luck nonetheless!
@Gili: As I’ve said all along, this thread is meant to facilitate discussion. Discussion isn’t facilitated when you’re pointing out peoples errors – it makes people shrink back inside themselves and become afraid to contribute. That is a basic rule of any brainstorming session.
The next step of a Swing 2.0 discussion would be to be critical on all ideas put forward. To try to rush the process means we get an incomplete picture. For this reason I have purposefully be very supportive of almost all ideas.
Whether or not we get to the next stage of Swing 2.0 discussions is another matter entirely, for I fear that whilst there is a huge desire for the project, the time requirements and complexity would be prohibitive for the kind of people that have the skills required.
In my private discussions with various people I would consider skilled, they have all indicated that without support from someone like Sun or similar, they would find it very difficult to dedicate enough time to see the project through to completion. The same goes for me.
Cheers,
Jonathan
I haven’t read this whole thread, but I’d like to throw out a few simple items (that may have already been added):
1) I suggest incorporating proper separation of subfocus from selection in complex components like lists, trees, and tables – ala JBCL. The “current” item receiving keyboard input has nothing to do with the selection set.
2) The LookAndFeel system needs to be rethought from the ground-up to make for an inclusive model. Swing2 should not be a “closed” set of components (library), but a core set of components with an open model where 3rd party components get equal billing by design. This can be achieved using a “skinning” look-and-feel model like in Nimbus – but bake that notion into the lower level rather than implement a skinning LaF.
3) Bean-binding: I agree on data binding needing to be there cleanly – but there are a lot of debates around proper binding techniques. I suggest a more formal datamodel+address based system rather than loose coupling via string expressions. Type safety and runtime metadata are very very valuable when designing usable tooling. Ping Richard Bair on this topic – he’s got a bunch of good stuff we cooked up for JSF/Creator and SwingLabs.
I’d be happy to lend some experience, but as I’m sure you guys can appreciate… time is tight for any volunteer projects.
– Joe
@Dan Howard:
> For swing2 why not drop the layout managers and follow the MS way
> of using containers with relative layout.
This is how Pivot (http://pivot-toolkit.org) handles layout – see my earlier posts on this thread for more info.
-Greg
re doing this as an “unofficial” project–Adding support for generics/better general support for collections to the Swing data models is something I’d be interested in helping with and willing to throw some free time at.
Something I’m not understanding is the desire to “drop” layout managers; even if you don’t like them and would prefer to do things another way, wouldn’t it be logical to simply extend what’s there? Swing already allows use of absolute pixel positioning instead of layout managers, so it should be possible to build other layout mechanisms into the toolkit.
You should know that there already is somebody putting generics in swing on the openjdk project. Check the swing mailing list.
@bvv: Yes, that person is linked to in my original blog post – Swing-Generics available from https://swing-generics.dev.java.net/. That would essentially be the Swing 1.5 that I talk about.
One thing I would like in a new API is a change to the heavy EventListener stuff (which induces high coupling between SW components) into a lower-coupling solution. EventBus (or any equivalent) comes to mind. It would be good if Swing2 components were built with EventBus in mind (eg S2 components may push events on various named topics; these topics would be named after the component name -provided it is made mandatory in S2, which is a good practice- and the kind of event -rowselected,focuslost…
A second interesting point I have seen in the comments here was about removing the heavy bean-style properties of Swing components. Without waiting for a language change (I doubt this will ever come one day), there are some interesting solutions out there (bean-properties on java.net is one, but it is interesting only if it is natively supported by the components, which is not the case in Swing of course). Such a change would enable better -and easier, with less boilerplate- binding toward Components properties.
Read this blog, read Danny’s blog. Haven’t touched Swing in over a year. Last touched messed with it using 1.6 and in all honesty I have never understood why people call Swing complex. Have never had to mess with Swing at a low level (e.g. overriding graphics methods, etc) so my comments come from Enterprise App point of view.
I mean I’m doing WebDev and the difference in complexity is like “woah” (in favor of Swing).
Swing is easy but could be made easier, as in frameworky – similar to Spring Rich. Hence the point I am in total accordance raised by Jonathan is: “Improved support for bean binding and validation”. Spot on – great observation.
p/s: Awesome response to the Dimitry-guy. I mean I can spend my time trolling C++/GUI toolkit forums and just ripping them on how complex it is to get a screen to pop-up. What a knob!!
@Kondwani: Thanks for your input. I think Swing is complex if you are unwilling to commit to understand its nuances, but then, that’s true for most things in life, particularly APIs. I think the main aim is to take what we have, and try to clean up the API. It pains me every time I’m looking for a method and it’s embedded in 100s of methods – I have to play guess the keyword, and more often than not, I end up scrolling through a huge list of methods to find the one I need.
Things like generics, varargs, enumerations just make the API cleaner, and make it possible for our IDE, and our compiler, to help us more at compile time rather than have errors at runtime.
Thanks!
I’ve been knee deep with Swing for … good 8 years now. And I really like it, even with all it’s quirks. Powerful tool.
That said, I’m envious to other languages of their power. Take Objective-C as an example, they’ve got really cool properties, and creating user interfaces that sync with variables is a breeze. I’d really like to see this in Java. I think that would really take it to the next level.
That one language feature would make recreating swing much more worth the effort. Otherwise I fear it will just be trading one bad aspect to another. To put it plain, Swing was a huge undertaking. Swing 2.0 will be huge as well. It will be defected in some ways and there should be fundamental differences that would justify the godawful amount of work.
But I do agree with you guys, things spoken here would really mean a lot to Java.
If there were one thing I’d like to see changed in a Swing 2.0, it’s the monstrous way look and feel delegates are installed. Running foreign code in the superclass constructor of your component is a horrible antipattern – and in Swing is THE pattern.
I can’t count the number of bugs I’ve seen because of this, and bewildered programmers I’ve helped who were seeing inexplicable heisenbugs because one or another look and feel tickled a code path they hadn’t anticipated before their component was full constructed.
What about the possibility of wrapping the JavaFX stuff in java so the java API looks swingish, but underneath you get all the JavaFX flexibility. This way you don’t have to deal with old legacy stuff, you get 100% flexibility in terms of how you draw your components, and users of your API don’t need to know about JavaFX (if you’ve done a good job). Also means your app will run anywhere where javaFX runs.
The tooling for JavaFX is still pretty poor, there is a lack of components, and it’s a whole new way of programming.
I’ve had a play with JavaFX to create a swing like GUI for editing a bunch of beans, tables, lists etc, and it toke a lot of work. Using Swing and the JavaBuilder library was much easier.
However, JavaFX does have many cool things you can do with it, which would be cool to have access to in Swing.
So IMHO if the two could be married nicely we would have the best of both worlds.
@Bert: I’m not familiar with JavaFX – could you please point out what do you mean by “cool things” in it?