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.
About painters… How does that mix-’n-match with Look and feels? You still want to be able to have a way to buy a skin, so painters should not conflict with skins.
I am an idiot because I’ve added a touch of sarcasm to the discussion?
@Dimitris Menounos: Sarcasm does not translate well over the internet if you don’t make it clear with emoticons or equivalent. So yes, you are either an idiot for stating what you did, or an idiot for not making your sarcasm clearer.
Please feel free to come back to the discussion if you have a proper opinion (I would love to know your thoughts in a clear, more objective manner)!
@Tbee: I agree that we keep it simple to start with. But as with any project, it is best to think twice, code once. What I mean is that whilst there is no code lets talk about what we would love to have in a Swing 2.0. Of course, everyone throwing ideas in is going to result in a scarily long list of things to do, but that’s assuming we are by default doing everything, which of course we aren’t.
The end result of a discussion is a huge list. Following this we need to prioritise and work out interrelationships between the items on the list. We pick out the ‘easy kills’ and the more difficult tasks.
I also tend to agree that Swing 2.0 builds on top of Swing 1.0, in the sense that we start by taking all Swing code, and building and refactoring from there. I would love to hear more thought from people regarding this.
I take your comment regarding JavaFX to hand, but with me being completely lacking in any understanding of JavaFX, it is easier for me to dismiss immediately
Seriously though, if you think there is a possible link, then it has now been recorded in this discussion, so it will be considered more seriously in the coming days should Swing 2.0 go anywhere past this one post.
Cheers!
I am almost agree about codebase for swing2 to be swing1. But It will
not be good to do big copy-paste of code, it will be hard to find and
clean all old code that is left for compatibility reasons. May be it
will be much better at first just to wrap currently existing
components and then to implement it all step by step, until only some
core Swing1 parts will left.
Another question, you said about generics and varargs, but how will it help you? You are right, I am not working with Swing all day long, but I am fan of Swing and I am using it almost all my free time for my opensource projects. And I can feel differenct leaks in Swing, but I can never feel the leak of generics or varargs or enums… And of course i am interested in how are you using it and how can it help you?
@Aekold: Thanks for the comment. I do not know the best way to start with a Swing 2.0. I am certain that Swing contains a lot of useful code, and is sturdy having stood the test of time. I for no reason advocate throwing that away and starting Swing 2.0 from scratch. At the same time, I do not know how best to start a Swing 2.0.
My inclination is to take Swing 1.0 and slowly refactor it to meet the needs of Swing 2.0. This will require discussion and an understanding of use cases. But it also means that we are trimming the hedges rather than planting the trees, which is far easier, quicker, and more likely to succeed. I would note that the general feedback is to not care about backwards compatibility, which will certainly accelerate the development of Swing 2.0 if it is built atop Swing 1.0. If you disagree please let me know on your preferred approach to a Swing 2.0.
There are numerous examples in Swing where generics will be beneficial. For example, in comboxes you can ask to getSelectedItem(), etc, and because the component does not support generics, it returns an Object, rather than the type of the object that could be specified in a generic argument.
@Jonathan It’s not about starting simple; all the stuff that could go into Swing 2 is complex enough. It’s about scope; it’s about Swing 2.0, not “properties in Java” or closures.
The starting point must be the API not the swing legacy code. If your keeping the Swing 1.0 API then your stuck with the backward compatibility problems it has.
If you’re re-thinking the API then you have to start by asking yourself who will be using it and how they will use it. So do you only want the Swing 1.0 developer to use it? Or do you want to broaden your audience?
Wait a minute … doesn’t it looks like exactly to what Sun is doing with JavaFX?
@Tbee: Absolutely agree about scope, you cleared that up perfectly. You’ll note my initial post said the same thing about it not being about properties or closures. Swing 2.0 is not about healing the Java world, it’s about patching up Swing to be more closely aligned to the needs of desktop Java developers. We need clarity of scope, and hopefully this discussion thread is a step in the right direction.
Lets keep this discussion going, and see what other people have to say. In a day or two I’ll make another post to clarify the discussion and try to boil down the comments.
> Wait a minute … doesn’t it looks like exactly to what Sun is doing with JavaFX?
Except JavaFX isn’t Java…
I’d say start from scratch. It won’t be backwards compatible anyway. At least not in the sense that one can use them interchangeably. On the other hand Swing 2.0 (called SwingIT!) should be very very familiar to current Swing developers. When modularity comes SwingIT can just be used instead of Swing 1.0 for new projects.
What you are looking for is already here:
Jazz Desktop Application Framework
http://jazz.coderight.nl
@CodeRight: Simple, Jazz costs €1500 per developer.
@Thierry Lefort: You make good points, and I do not have many of the answers. I hope others can fill in the blanks.
All I know is that Swing, as it currently stands, is pretty damn good. What it’s missing is a cleaner and more powerful API. I do not want to program in JavaFX, the language does not appeal to me at this point. I also have lots of Swing code that I would love to see being moved to Swing 2.0, to gain the benefit of as many of the features discussed above.
Therefore, the big question that needs clarifying I believe is how does a project like Swing 2.0 start: Do we build it atop of a potentially broken Swing 1.0, or do we build it from some form of scratch? There are benefits and pitfalls to both sides.
At the end of the day, I want to be programming Swing. In my opinion, Swing 2.0 should attempt to be as backwards compatible with Swing 1.0 as possible, because the last thing anyone needs is another API to learn..
That is my opinion, please discuss and disagree. Unfortunately for me I really need to call it a night, so I’m off for now. I will open up the blog so that comments do not need authorisation so that newcomers to the blog can post straight away.
Cheers.
@Mikael Grev: I agree with your statement: Swing 2.0 should be a GUI language familiar to Swing developers. That is my primary endgoal.
Starting from scratch seems to be the prevailing sense of direction. The question then becomes how can we accelerate the development so that Swing 2.0 is a huge, huge project? Can we make use of what already exists in Swing to accelerate areas that possibly don’t need as much focus?
Current Swing have tons of code. Only looking inside JTable and JTree you have about 10000 lines of code. It looks for me that it is utopia where all this code can be cleaned. There are too much of code left for compatibility and other reasongs, that will be dead for Swing2. While debugging parts like this – sometimes it can take you few hours just to figure out what parts are used and what parts are not. I think that first step – to write some specification for the component. Implement all required methods to declare some component interface, and at first just to wrap existing component. Than all used parts may be copied from existing component. After it will be completed – you will have clean component with no compatibility or dead code. There is always another way – just to look how Qt (being a bit supreme to swing in desktop) moved from 3 to 4 and use their experience. It’s a shame I don’t know how they did it…
About generics and other… I never thought about casting something is a bad thing in your application, and other things like this. It takes you few seconds, while creating some TableColumnFactory and implementing some AbstractTableModel to be able to add elements, or implementing something similar to code completion, or even just detecting doubleclick… It consumes lots of time, at least in the stage of creating new application. Generics, enums and other is just some piece of API you can learn and use, while customizing your components or making your GUI customisable takes all the time.
Oh there we are … JavaFX is not Java … I knew it was a religious debate not about technology.
Sun should buy JIDE and license it as LGPL. There you have your Swing 2.0.
Current JIDE License is not so expensive you should give it a try. After all it is one of the best(if not THE best) Java based GUI toolkit ever.
http://www.jidesoft.com/
Man! What a lively discussion! And the US of A isn’t even awake yet.
Considering that the intention is to break of backwards compatibility on components, IMHO it is not wise to refactor existing code. Swing 1.0 exists and should be untampered.
So my suggestion on starting Swing 2 (after collecting the features) would be a technical discussion on the basic API and structure of a component (how to do painters, layout, skins, etc).
Then write the J2Component (extending JComponent), and next a J2Label & J2TextField both extending J2Component and get a serious set of unit test going to drill out the features we wanted.
After that scrollable stuff (J2TextArea) with unittest, refactoring. And if we got the kinks out of those, then it may be time to consider compound components like tables, lists, etc.
@Thierry Lefort: I would tend to agree, JavaFX (the language) is not Java (the language). It’s easy to prove: I can program Java (the language) but not JavaFX (the language).
This isn’t a religious debate, it is about accepting that JavaFX has its focus, and Swing has its focus. They may overlap, but they are also different. I write my applications in Swing, because I know Java (the language).
A company I am involved with did buy a Jide license for me and I have used it extensively. It is a great component suite. It is not Swing 2.0, for the reason you state: it has to be purchased. In addition, it is used in conjunction with a Swing 1.0 application, and it is Swing that is failing the developer, not Jide.
Cheers!
For me is Swing 2 Groovy and its builders.
@Tbee: Thanks for the pragmatic advice. It will definitely be interesting to see what the US has to say about it
As I mentioned, unfortunately it is late here in New Zealand (getting on to midnight), so I need to head off. I hope you all stick around and keep the discussion going – we need to get a consensus on what a Swing 2.0 means to you.
Discussion is open (no prior approval needed anymore), so I imagine discussion will continue to be lively for the coming hours.
@bubak: Perhaps you’re correct if you’re a Groovy developer, but for the sake of this discussion, the focus really is on answering the question ‘how can Java (the language) be improved to make developers GUIs easier’? The answer almost certainly revolves around taking a syntax and to a lesser degree an archiecture similar to that of Swing and improving the rough edges.
In summary, I do not want to learn a completely new API. I want to take my Swing knowledge and be more effective when developing GUIs. I want Java (the language) to work as effectively as it can, which means making use of new language features, etc.
@Thierry Lefort I am totally agree with your points of Swing2, but also I am not a fan of JavaFX. It will be great to make it possible for both Java and JavaFX. It is just some experience with languages without strong types. Don’t declare it is religion vs technology, I can say similar – JavaFX looks for me more politics than Java. Java is suffering from own backward compatibility, but it is suffering of rt.jar but not langspec.
+Model Simplification. Model af swing should be massively simplified.
Wicket Model is a good exemple of where to go. It is not possible to have a model for each componant. in the end, you have too many class to know.
(Edited by Jonathan: I assume that ‘=Model simplication’ should have read ‘+Model simplification’. Let me know if I’m wrong and I’ll return it back to how it was).