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.
I’d like to see some sort of XML layout similar to Flex. Divorcing layout and Controller makes it so much easier to modify. Easier to build WYSIWYG editors, and easier for newbies to do Swing without wrapping themselves around the axle. Better layout managers! TableLayout is fantastic so much easier to GridBagLayout, and simpler than say SpringLayoutManager.
I’d like to see a better component lifecycle model, again this is where Flex is much better than Java. Swing as it stands makes it difficult to create properties you can adjust at runtime.
I think Adobe’s Flex platform is a great client platform, and Java FX has got to get a lot better if thinks it can compete.
CSS skinning, while it’s a little awkward in Flex, but something like that would be great for creating new looks easier so graphic designers can create new looks without coding ala Scale9.
Java’s 2D library is vastly superior to Adobe’s so there is potential to capitalize on that.
@Charlie Hubbard
No XML please! Using it gives up type safety and compile time checking. It is the curse of many systems I’ve worked on and, while fashionable, is used in many places it ought not to be.
I would prefer to work on Swing in Java *only* thank you very much. If a tool uses XML that’s fine, I’ll just avoid it or never look at the generated XML, but please don’t foist XML on users of the Java programming language as part of the Swing Core.
For example, I consider the JPA (Java Persistence Architecture) to have bad design flaw in that at least on XML file is required, you can’t specify everything with annotations or Java code. A poor design choice if you ask me to require XML files hanging around.
Nope, Swing should be codable in 100% pure Java. Keep your XML-hell to third-party frameworks thanks.
@Charlie:
I agree with you about separating layout to an external file. I personally would prefer to use JavaBuilders ( http://code.google.com/p/javabuilders/ ) instead of XML: it is more compact and readable (IMHO.)
-Alex
@Charlie:
At the same time I also like the API that DesignGridLayout ( https://designgridlayout.dev.java.net/ ). IMHO, it is pretty intuitive and it allows us to benefit from static typing and tools.
-Alex
To all, I have now actively set up the mailing lists at http://kenai.com/projects/swing2. I suggest anyone who is interested sign up to it and let us hear your thoughts. I will likely start posting to it shortly also.
> I’d like to see some sort of XML layout similar to Flex.
Pivot supports UI construction via XML, similar to Flex and Silverlight.
> No XML please! Using it gives up type safety and compile time checking.
…but it is optional. You can also construct your UI entirely programmatically, if you prefer.
I second that motion. No XML (or any other external files) should be necessary by default. If you want to use them feel free, but by default we should be sticking to type-safe pure Java code.
Image management also suck. There a bazillion ways to load an image, and no component to simply display it, see http://weblogs.java.net/blog/timboudreau/archive/2009/02/how_not_to_writ.html
I have read some post which look more like a thesis about “compatible” or “managed” or “intermediate” image, for example :
http://weblogs.java.net/blog/chet/archive/swing/index.html
this post is 30 pages long in word !!!! And I don’t understand a single word from it ! There should be only one way to load an image, and this image should be always managed in the best way possible without having to deal with such concepts.
myPanel.add(new JImage(‘/swing2.png’));
or
Image img = new Image(‘/swing2.png’);
filterOrDoOtherStuff(img);
myPanel.add(new JImage(img));
remove all the others things.
sorry, the url for the second post was :
http://weblogs.java.net/blog/chet/archive/2004/08/toolkitbuffered.html
Swing is in fine fettle and is not being replaced by JavaFX in my opinion. I am not versed well enough in JavaFX to see how well the two will integrate within one application, but it seems, we can pass processing to JavaFX if our desktop Swing apps need a browser / web 2.0 aspect. New stuff for free. I’d call that a win.
Regarding Swing’s continued evolution, I would like to see:
Scenegraph de-GPL’ed in the form of classpath exception , like the rest of Java.
Graph component.
Continued progress with FlyingSaucer. I think this is important because the future of all text is XHTML, and we need to be able to read/write XHTML. It’s more basic than even a browser in some sense.
Continued work with Filthy Rich Clients – too bad about those guys leaving for Adobe; they’re definitely going to be missed.
Continued work from independents in the form of widgets and tools, especially tools in Netbeans.
Netbeans is “our” development tool (OS, pure Java, supported by Sun), and any progress there in the form of tools that makes us more productive is a force multiplier for Swing developers.
Swing is hands down the greatest GUI toolkit in existence. Desktop apps written in Swing are going to continue to grow deeper into the longtail marketplace.
Jackass, er, I mean AJAX, is a poor substitute for the power of the desktop; watching a AJAX application always reminds me of what Dr. Johnson’s quote ” is like a dog’s walking on his hind legs. It is not done well; but you are surprised to find it done at all. …”
The relationship betwen Swing and JavaFX is not one of competition, its more like Java’s been extended into the whole Web 2.0 arena all at once, rather than growing there incrementally. That’s a huge win- we now own that space.
The desktop is good for
1)fast, real time rendering of GUIs and effects
2)instantaneous feedback from user gestures
3)access and processing to data people don’t want to put on the web
That adds up to the ability to write very very rich GUIs which process local data. A local machine will always respond faster than the the same network-based processing.
There’s no reason to think that desktop applications for which the amount of local processing is more than sufficient to render reactions to user’s actions are ever going to go away. That part of the computer is NOT the network.
So Sun pumped some resources into Web 2.0. So how does that hurt us? It doesn’t.
I have a small suggestion.
1) make ALL constructors protected (enforced by a compile time annotation).
2) Provide static factories for each component (that capture the generic type).
It’s the old issue of
Map<A> map = new HashMap<A>();vs
Map<A> map = Hashmap.map();plus these methods could be used for subclasses configurate things *after* the constructor is called avoiding a whole category of problems.
I don’t know this idea might have some problems.
Hey Jonathan,
I was breeding on this multithreading issue with Swing… Would it be possible to write a GUI framework that never ever blocks the painting thread (EDT)?
I was thinking along the approach that is used with device drivers. Each device driver usually has two separate “threads”: one the reacts to hardware interrupts and reads data from the hardware and writes that to a buffer. Very quickly, in order not to block the next interrupt. Then another thread, running in the application reads that data from the buffer. Sempahores are used to synchronize.
Mirroring that to Swing would make the EDIT the interrupt thread. That would mean that any event that comes out of the GUI must not be running in the EDT, so a special event thread is used for that. Maybe even a thread pool, but that would introduce asynchronous behavior and Swing currently is synchronous.
And any thread calling into the GUI components may only set a property, but that information is never propogated by that thread to the actual GUI. The component is marked dirty and the EDT does the repaint. Sempahores are used to temporarily lock a component while the EDT reads data.
So the EDT never ever executing application code.
I understand that deadlocking issues may be the problem here, when the EDT tries to lock a component for reading… That is where the challenge lies.
Jonathan: you are 100% correct.
One of my main historic complaints about Swing has been the horror of LayoutManagers not behaving quite like I want them to (e.g. GridLayout blowing up buttons to huge sizes). This problem has seemingly been solved: I recently did some Swing coding with GroupLayout, and to my surprise and pleasure, discovered that it seemed to behave almost perfectly outof the box. Which is the way things ought to be.
But one confusing area for Swing, at least for me, is with the whole validate/invalidate/revalidate/repaint thing: sometimes Swing works automagically, sometimes it seems to require manual calls. Am I just a moron, or should this not all be simplert o understand and user?