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.
@Tbee JComponent is not the best way to start. It is better to implement few working components and then move everything they have in common to J2Component, but not start from what they MAY BE WILL USE. As for me specification should be more feature specific at first, like requirements. And then to write strong architecture to solve all requirements.
I couldn’t agree more with a need for Swing 2.0. Just point for discussion – do we really need to stick to the EDT concept? It quite a pain in the ass – you still have to think “am I in EDT or not?”
I like the way how game engines typically work – they got scene renderer looking for components with “dirty” bit which is automatically setup once some of it’s properties is changed.
@Abraxis: Thanks for the comment! Not that I’m a games expert, but I suspect that they are largely special cases. Multithreaded general purpose programming languages do need to have compromises, and as far as I’m aware, no one has really had any luck making a multithreaded user interface library.
For that reason, the user interface library has to run on its own thread. Whilst it’s certainly not ‘nice’ in terms of code cleanliness, I don’t thinkwe can really question its necessity. I think the best thing that Swing 2.0 can do is just (and I know you’ll disagree with this) harshly enforce the requirement that all gui-related operations occur on the EDT, and all time-consuming/slow operations occur off the EDT (apart from when the GUI is being updated).
How harsh is a matter of discussion. I would be happy to see my console littered with runtime exceptions. I personally feel that is the happy mix between having checked exceptions (which just doesn’t feel right in the slightest) to having the EDT checking being optional (which I think will just lead back to what we have now with Swing – ‘slow and broken GUIs’ as a result of developers not knowing EDT rules). Therefore, I believe it should be fixed at runtime exceptions without scope to change this setting.
That is my opinion anyway, from an oft-confused EDT abuser
@Abraxis RepaingManager works like this already, you can mark some area of component like dirty, and only dirty area will be repainted. But the problem of EDT is not repainting – repaint() is thread safe already. Problem is every setText(), setIcon(), setAnyOtherStuff() should be invoked in EDT even when repaint is not required, and of course you can’t control like this:
1 – set other text
2 – set other icon
3 – and now it is time to repaint
because repaint is triggered almost in any component change.
Somewhere is was told that it is done for component developers should not know how multithreading in Java works… Two questions: 1 – isn’t it good for any Java developer who is working with advanced features like component creation to know what multithreading is and how to handle it, and 2 – all this EDT panic helps you not to think about multithreading for a moment? I am not sure…
Hi everyone!
What about use the signal\slot behavior as in Qt(http://www.qtsoftware.com/)?
I’ve used them in C++, they work almost like simple binding.
Also i think properties are something need!
The aproach a.value++ is much better than a.setValue(a.getValue()+1).
But i didnt liked much what ive heard about properties in java7, theimplementation doesnt look good
public String get name(){
}
@Jonathan
Jazz cost money because I invested over 5 years of my time to develop Jazz and I would like some return on investment.
When Jazz was ready to go public we gave a demo to the Swing team (Hans Muller, Richard Bair) and offered Sun to open source Jazz on SwingLabs but Sun had no interest (not reinvented here…).
I am are aware that because Jazz is not open source and not for free limits it’s use so we are thinking of open sourcing Jazz as well.
I am open to suggestions to open source Jazz and make it the defacto standard Swing application framework but I am wondering what’s in there for me? I guess it means the end of my company then…
@Jonathan What you say is right – it is better to throw exceptions, than developers will learn about EDT. But there are some basic methods like setValue() or setText() or setIcon() or other that are better for you to use out of EDT (because of some background threads) and those methods should be implemented in thread-safe manner. It is hard to make whole component thread-safe, but it is not hard to make few data changing methods thread-safe.
@Aekold One could make methods behave two fold: if inside the EDT, well, just do it. If outside the EDT, create a runnable that does the thing and run that with invokeLater.
The problem in the latter case is that when (for example) the setText method exists, the text is not yet set. That is very unnatural. And if you use “invokeAndWait” instead, you get into all kinds of locking drama’s.
Been there, done that. I found it to be not a great idea, but it can work.
Im a long time Swing contractor and my main beef with it at the moment is simply that its starting to look a little old hat. The look and feels including Nimbus just don’t cut it in the current market place. When I give demo’s a lot of comments from customers are usually made about how 1990′s things look.
Now I can play around with gradients within Java2D to improve things some what but its all effort that I think should be simple. Making my own L&F is simply not an option as its so damn hard.
So I think effort is needed into making the look of Swing flasher. I’d also like to see some of the property binding thats been introduced into FX.
I suppose what I’d really like is some of the nice new FX features but not the FX scripting which to be honest I don’t like at all.
@Aekold The best approach usually is in the middle.
My main point is that IMHO one should shake down all the features that are to be implemented with a very limited number of components. And that is something that is quite doable and we could get something working within a limited timeframe.
I still feel extending JComponent to be wise, in order to preserve Swing 1 and 2 integration; the core engine of Swing should be reused.
@Jonathan: I’m neither game expert nor developer so I just got general idea how it works.
My point is that for “simple” calls like setText/setIcon (which IMHO are 80% of uses) you should not really care what thread are you in. And if you need to wait till component is repaint with your change, then just have something like setText(“asdf”); waitForRepaint();
To sum it up – doing this does not break EDT-aware programs (just EDT-related things could almost-ignored) – but it’s practically impossible to rewrite later Swing (1.0 or 2.0
) to support this non-EDT paradigm.
Forget about using enumerations instead of static ints…I did an enhancement request for that and it was explicitly rejected by the Swing team.
Backwards compatibility is king it seems, fixing broken API is secondary.
> I still feel extending JComponent to be wise
Then you can’t fix the API. Take JButton. It’s a simple button that extends JComponent. It has over 400 methods!
Yeah, I want to Swing2, too. I’m interested in Swing, although some says its too difficult to learn, But I’m not quite agree with those. JavaFX is cool but I don’t like it. I think its code is quite strange, not as Swing or other tranditional language. I want to learn Swing2.
Regarding multi threading.
This is generally much harder than many might think.
Though with real properties you could have ConcurrentProperty instances to handle setting from any thread.
@Mikael True. But you have to keep some kind of integration with Swing. What would you suggest?
Naturally we only require Swing components to be renderable in Swing2 (just like JavaFX does, hmmm).
Hi,
I agress will all thoughts.I m biggest Fan of swing.
Best solution is Framework for swing,the biggest reason for swing failure,bcoz its easy to develop ugly UI easily & EDT mistakes.
Web development is easy in Java bcoz of 100 web framework,that gives each developer choice to develop apps of his needs.So thier has
to be framework that take care of bean bindings,EDT mistakes,Animations.. etc that you proposed, their should be not 1,but more framework of choice to make more developers happy.With JavaFx on Sun’s mind,I do not think Sun will help.So others guys like us need some work on this.
javaFx is good solution,but its still not ready for Enterprise yet.
Mine biggest prob. with JavaFx is JavaFx code are hard to read & understand in one go.
Lets hope for best
@Tbee
I would suggest something in the line of what JavaFX does. Wrapping normal Swing components.
And, that the Look&Feel classes are made so that Look&Feels are super easy to port. They are reasonably disconnected from Swing so it shouldn’t be much of a problem.
It is imperative that Swing 2.0 doesn’t depend on 1.0 in any way so that when it takes over the Swing 1.0 module doesn’t have to be loaded at all. This means that we can actually gain startup time and get a smaller download size.
I wonder how much Pivot already fulfills some of these requirements you all have been suggesting? I don’t use Pivot on a daily basis but it might be a path in the right direction?
http://weblogs.java.net/blog/gkbrown/archive/2008/06/introducing_piv.html
http://code.google.com/p/pivot/
Here are things I’d like to add to Mikael’s posts.
1. Retained mode API – The desire for advanced effects and painting outside a component space needs a retained mode API to determines when parts of the screen need to be updated. We already have scenegraph so that work is actually already done. We just need a good API to use from java.
2. Easier creation of models. The Default* models are abused to no end because creating a custom model is considered a ‘black art’. I find direct data binding to be an anti-pattern. There is nothing MVC about it. I’ve written reflection based code to map bean properties to columns so I can just display a list of beans as a table. There should be a more performant/more generic way of doing this.
3. EDT – Lets look at the alternatives.
a. Foxtrot (http://foxtrot.sourceforge.net/docs/index.php) has a very tempting approach. It allows the synchronous style of programming that currently is considered wrong. If there was going to be a Swing++ then making the changes necessary to support a Foxtrot like system would make scene.
b. Fully Asynchronous API. Integrate with asynchronous IO to create an event derived io system specifically for swing applications. Seems less likely and requires programmers to always write asycn code. I think Flash does something like this though.
c. Fast fail. While I hate runtime exceptions it would be a quick way to catch common problems. And to those who think they are smarter then the EDT, you aren’t, and your “safe” component probably isn’t really safe.
There are no multi-threaded UI toolkits out there. It has been an idea attempted and failed by people a lot smart people. Better single threaded interaction is the way to go.
4. Better layout managers. along with that a better API for interacting with layout managers. We should not have to embed all the parameters and string ot get the verbosity we need. I proposed adding a varags parameter to addComponent() to help pass lots of constraints. More ideas like this, or some way of using Enums, or annotations or something to give us a readable and maintainable layout system.
5. A Docking Framework.
6. JWebPane … hopefully this will be released someday ..
7. Real MVC design. Swing as it is now is only “model-separated”
I will post more when I think of them.
… True. But you have to keep some kind of integration with Swing. What would you suggest?…
You can do what JavaFXScript does, wrap it in an adapter class.