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.
@Gabriele Carcassi: I am trying my best to organise a Swing 2.0
. The only reason I have gone quiet is because I’m waiting to hear back from Sun. I would dearly love to get their feedback, and based on their comments so far, they may generally accept some, but not all, of the Swing 2.0 points in this blog. This is reasonable as this post has contradictory requests. I purposefully kept my initial post shortened to what I consider the minimum requirements for a Swing 2.0.
Perhaps instead of Sun accepting a need for Swing 2.0, they will possibly support a ‘Swing 1.5′ (Thanks to Rémy Rakic for that term) – in other words a more basic upgrade of Swing to support Java 1.5 features. This could be a good start.
Anyway, enough crystal ball gazing – I will update when I hear more.
@Johnathan Kia Ora
“I think the problem with any API is that you need to know all of it to be a power user.”
That’s not so bad. The problem is not with us power users, I believe is the fact that you have to know quite a lot of Swing’s implementation details (EDT etc) to be able to do anything other than the simplest things.
Again, there’s no default way to display things such as dates or currency that appear in a large proportion of applications. It is not that it is difficult to do, it is the fact that you have to do any work at all for these simple things that is a design flaw in the default set of Swing components. Building CRUD applications (that can display common SQL-derived data) is far, far more work than it needs or ought to be.
Fingers crossed Swing 2.0 makes a difference. Thanks for giving us a forum to air our ideas.
I think that a swing 2.0 should be a “pimped” edition of the swing that is built on the Scala language, extending Scala’s unique language features.
http://www.scala-lang.org/
@Mike Reid: ah, looking at your email I see we have another Kiwi on the site
You may or may not recognise the images in the title banner on this site as Waiheke Island. Anywho, I digress.
You make good points. I push for a Swing 2.0 that enforces total EDT compliance. Like I said in my initial post, it will make developers unhappy until they learn the rules, but it makes the end result far better. It is worth it.
Additionally, there may be scope to improve the means of interacting with the EDT, but that is a discussion for another day.
I would like the following in Swing 2.0….
…I would like to replace AWT with SWT.
…I would like an interface-based UI that uses a factory to create instances such that applications can plug into the factory to customize components. This enables me to use Swing API to develop most any kind of GUI, the specific implementation of UI toolkit can be customized by application.
…Removal of ‘renderers’ from API. Renderers prevent using Swing to develop thin-client UIs since the renderer concept does not translate well to client/server architecture.
@ted stockwell
There is already an implementation of Swing on SWT, called SwingWT
http://swingwt.sourceforge.net/
Incidentally, SWT works best on Windows and less well on other platforms (IMHO). It certainly has a lot of subtle inconsistencies between platforms (at least for the products I’ve built with SWT). In addition, SWT’s internal implementation ‘style’ seems quite Windows-like and old-fashioned (eg. variable namimg) compared with the Swings – but as I said, this is just a style thing.
Pivot does indeed address many of the issues raised in this thread.
It was recently accepted for incubation by Apache, and the incubator proposal provides a good overview of the project:
http://wiki.apache.org/incubator/PivotProposal
Additional information, demos, and source code, are available on the project site:
http://pivot-toolkit.org
Just wanted to share some specific examples of how we have addressed a number of these issues with Pivot:
* “Generics-based, support for enumerations where obvious” – Pivot requires Java 5 as a minimum, which allows us to take advantage of newer Java language features throughout the API.
* “Improved support for bean binding and validation” – Pivot’s built-in data binding framework makes it very easy to bind bean classes to form elements.
* “Better handling of the validate/invalidate/revalidate/repaint mess. You should never have to call these as a developer.” – Unless you are developing custom components, you will generally not even need to be aware of these methods as a Pivot developer.
* “Layered painting build in from the start.” – Pivot’s decorators serve exactly this purpose. See http://pivot-toolkit.org/demos/decorator.html.
* “Components should be able to paint outside its bounds.” – Decorators are also used for this.
* “min/preferred/max sizes should be width/height and not size.” – Pivot includes support for both constrained (i.e. width that varies by height or height that varies by width) and unconstrained preferred sizes (like Swing’s current preferred size).
* “All Components shouldn’t be Containers.” – Only components that actually make sense as containers are implemented as such in Pivot.
* “Better thought out listeners.” – We think we’ve done a pretty good job partitioning events into meaningful listener interfaces in Pivot.
* “A single Window ancestor that is actually used in the API” – Pivot’s Window class acts both as an undecorated window as well as the base class for other window classes such as Frame, Dialog, Popup, etc.
* “Adhere to the transparency of Colors. No isOpaque()/setOpaque(boolean) debacle.” – Supported.
* “Oh, and SVG icons is a good idea” – Vector images aren’t fully supported yet, but the API was designed for this. Both bitmap and vector images share a common base class so they can be used interchangeably.
* “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” – Decorators accomplish much of this.
* “Easier creation of models.” – The same model interfaces are used by all data-driven components (lists, tables, and trees), and there are far fewer of them. We think this makes them much easier to work with.
* “Better layout managers. along with that a better API for interacting with layout managers.” – Pivot containers and layout managers are not implemented as separate concepts – they are integrated. In our opinion, this approach is easier to work with, and is also the approach taken by Flex and Silverlight.
* “Real MVC design. Swing as it is now is only ‘model-separated’” – Pivot components are defined by a model, a component, which acts as the controller, and a skin, which serves as the view.
* “pure Java2D default PLAF” – Pivot ships with a default cross-platform look and feel called “Terra”.
* “more default component for usual things : DateSelector where art thou” – Pivot 1.1 includes a standalone calendar component as well as a drop-down calendar.
* “tables should have a default model that knows how to render simple objects put into it (date, text, boolean, dropdown, images etc).” – Supported. Pivot includes a cell renderer class called TableViewMultiCellRenderer that automatically renders cell content based on its type.
Throughout Pivot’s development, we often talked about it as “Swing 2.0″ – I’d suggest that anyone interested in the topic of “Swing 2.0″ at least give it a look.
Again, there’s more information on the project site and in the Apache proposal:
http://pivot-toolkit.org
http://wiki.apache.org/incubator/PivotProposal
Yes we need Swing 2.0, but I would say we should go further and try to consolidate everything we’ve learned since Swing 1.0 while we’re at it.
1) Widgets should address use-cases out-of-the-box without customization.
2) All forms of customization should be *heavily* documented and made as simple as possible. In my experience, Swing can do anything but no one knows how to implement it nor is it trivial to do so. I strongly believe we can do a better job the second time around.
3) One piece of advise: don’t freeze the API too early. I would advise freezing API components only if they haven’t changed for over 2-3 years. That should be enough time for the community to catch any design flaws.
swing 2.0 :
Painter,Timing Framework++(Project Scene Graph),JSR295,JSR296(need more simple),Powerful-LayoutManager(MigLayout,JGoodies-FormLayout…etc)
does anyone have other idea?
re painters: While I think the idea of painters is awesome (being able to replace specific parts of the painting code with your own implementation without going through the LnF hacking stage would be great) I do think that the current incarnation of them (in SwingX at least) could do with some work. For example a painter has no intrinsic size, this leads to separation of logic (in the bad way), for example in a TextPainter that is used to paint a label how does the label know what size the text is going to be so that it can decide on it’s preferred size.
On a related note one of the features that I would quite like to see re-thought in swing is the minimum/maximum size properties. These APIs, while having the best of intentions, could be accomplished using a single API that also provides much more flexibility for a component to define how it should be re-sized.
For example I’ve been experimenting with something similar and found that an API like public Dimension fitInto(int width, int height) allows for much more flexibility (for example you can define a component that maintains it’s aspect ratio, or only stretches in the vertical axis or has a maximum width or any combination) with a single api method. A similar API for painters (and scalable icons where I currently use it) could also be used.
Miglayout? Ha!
All we need is to start requiring Java programmers to instantiate objects with arguments like this: “[10][20:30:40][40!][::40]” (typical argument gleaned from the Miglayout guide in a few seconds).
+1 to better EDT enforcement.
+1 (and then some) to support for generics, and ditching Vector in every dang constructor.
-400 to the suggestion to remove renderers. . . DO NOT DO THIS!!! The capability to completely customize the appearance of complex components such as tables is one of the major reasons I currently choose to do GUI development in Swing; reducing the power of the toolkit isn’t the way to improve it.
Don’t think language-level properties should be required; the .NET implementation, at least, tends to make it extremely hard to determine what will and won’t automagically update; I’d rather have to explicitly call a method (or something) so that I know I’m updating a property and triggering changes elsewhere.
Having a good TreeTable or other multi-column tree implementation built into the toolkit would be really, really nice.
@gregor: You’re welcome to continue using current layout managers. I in fact have never used MigLayout (sorry Mikael!) – but I have used a similar framework heavily (JGoodies Forms). The question as to handling layout managers is a complex one – I understand their use, but I don’t know of a better way to handle laying out components if layout managers were to be wiped out of Swing tomorrow. Thoughts?
@gregor
A bit short sighted, maybe peek a few more seconds. I usually use one of the other syntaxes that MigLayout supports;
add(xxx, new CC().spanX(2).fillX())
Regarding EDT (again) – just an idea for brainstorming: Is there any reason why NOT to wrap every “setter” (.setText, .add – etc.) by something like this?
if (!isEDT()) {
Swing2Utilities.invokeThisAndWait(this.thisMethod);
}
Then Swing2 API would be “non-EDT” and inside we could keep using EDT or anything else in future.
@tbee
add(xxx, new CC().spanX(2).fillX())
is not much of a improvement over
“[10][20:30:40][40!][::40]“.
Look, I don’t want to bang on one Layout Manager or the other. The point is that if so many Layout Managers have been developed because those bundled with JDK suck, and even the new ones suffer from the need for such cryptic commands, perhaps some new thinking is required.
I think Java Sun people basically know this. As late as 1.5 they had to come up with a new Layout Manager, and they gave us the Group Layout Manager. The earlier versions of JFX had used Group Layout, but finally as far as I understand they have given up on it.
Imagine that JDK required you to specify your own hash functions for different type of objects, and the JDK came with a sucky hash functions that work only with Integers and Doubles.
The situation is similar with the concept of Layout Managers. They may be necessary evils, but a higher level abstraction is needed for the programmers who just want to show a nice looking table of components for example.
@Abraxis:
Nope, that would kill performance. It is better to consolidate as many actions as possible in one call to the EDT.
Cheers,
-Alex
@Abraxis: Alex is correct – you have to remember each time you put something onto the EDT you are creating a new Runnable, so performance would be killed by do each setter individually. It’s a nice idea, I have done similar in the past, but not at the level of setters – rather when I know a method should be called on the EDT but it may not – but I bunched together all EDT-relevant operations into that method so as to not kill performance.
I stumbled upon this discussion per chance. I think it’s an excellent idea and I agree with the majority of what’s been said. A cleaner simpler API would solve a lot of problems when developing gui applications in Java.
I am a bit surprised that very little has been mentioned about unit testing though. I’d personally like to see a framework or an ability to unit test my gui code. I’m currently using FEST which has become an indispensable tool to me. It however has a lot of shortcomings, most notably that the swing components are actually visible and the mouse cursor is controlled by the unit tests while they run. This leads to slow tests and also renders the computer unusable while the tests run.
Wicket is an excellent example of where a good simple (to use anyway) unit test framework improves the developers life in testing. A web server is not required to be running like so many other web frameworks.
In a similar approach I’d like to see some sort of test container that mimics the OS gui and the unit test in effect does not need visible components or the user of the physical mouse cursor.
That’s my 2 cents worth anyway. Nothing quite like dumping ideas on others that haven’t been thought through thoroughly.
@Jemsquash,
I’m pleased to hear that FEST has become an indispensable tool to you. I’m also interested in known the shortcomings you have found (besides the mouse-controlling behavior.) Would it be possible to talk about this in private or in the FEST mailing list? I’m always looking for ways to improve the project. Thanks
@Jonathan,
I apologize for talking about FEST stuff, not related to your post
Cheers,
-Alex
@Alex Ruiz: No problem – I’m glad testing has come up, as it was always something I imagined should be researched leading into a Swing 2.0, and if desirable, be made part of the scope. I’m sure an API designed with testing in mind would be nice for some developer. For that reason, it is great to have you monitoring this discussion Alex