posts/2009/swing-20/index

[JonathanGiles]

Java Swing 2.0

https://jonathangiles.net/posts/2009/swing-20/

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: January 26, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 26, 2009

@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 :)

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

@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...

[JonathanGiles]

Auto-imported comment, original author: Porfirio Comment posted on: January 26, 2009

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(){

}

[JonathanGiles]

Auto-imported comment, original author: CodeRight Comment posted on: January 26, 2009

@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...

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 26, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 26, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Steve Webb Comment posted on: January 27, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 27, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Abraxis Comment posted on: January 27, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Jacek Furmankiewicz Comment posted on: January 27, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 27, 2009

> 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!

[JonathanGiles]

Auto-imported comment, original author: Cheng Liang Comment posted on: January 27, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 27, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 27, 2009

@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).

[JonathanGiles]

Auto-imported comment, original author: Rajesh Comment posted on: January 27, 2009

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

[JonathanGiles]

Auto-imported comment, original author: Mikael Grev Comment posted on: January 27, 2009

@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.

[JonathanGiles]

Auto-imported comment, original author: Gregg Bolinger Comment posted on: January 27, 2009

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/

[JonathanGiles]

Auto-imported comment, original author: Aberrant (Collin) Comment posted on: January 27, 2009

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.

[JonathanGiles]

Auto-imported comment, original author: Aberrant (Collin) Comment posted on: January 27, 2009

... 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.

[JonathanGiles]

Auto-imported comment, original author: Alex Ruiz Comment posted on: January 27, 2009

Although I agree 100% with the spirit of this post (and most of the comments,) I think there is another aspect that we have not considered. Can Sun afford to work on Swing 2.0? We all know that last week a lot of people were laid off, and some of them from Desktop Java. Sun's stock has gone down in price big time. Even if Sun has all the good intentions to create Swing 2.0, I doubt it has the resources to do so.

IMHO, there is more than one aspect in Swing 2.0. First, the technical details (generics, enums, etc.) Second, backwards compatibility (which may be solved with javax.swing2 and Jigsaw.) And third, money.

I think it would be more likely that Swing 2.0 comes from the community than from Sun. I don't know if Java's license would allow this. I don't know what is really Open Source and what isn't.

Does it make sense? Or am I too pessimistic?

Regards, -Alex

[JonathanGiles]

Auto-imported comment, original author: Rémy Rakic Comment posted on: January 27, 2009

I'm all up for simplification, i think a builder/DSL might be interesting in this regard, not necessarily creating new component classes. If the latter was the way to go, not extending JComponent will obviously simplify things, a good thing in the long run i'd say, but a hard goal in order to cover the whole toolkit. (IIRC ken orr has this approach for his mac widgets for java)

A way to skin, or draw components in a visual tool, for instance SVG support not just for icons, but for lnfs and ui handlers. Painters are good, but i believe it would be nice to support artwork coming from designer over pure java2d code that'd need to be translated from comps. Either that or releasing the nimbus designer tool which generates java2d. I think it would ultimately lead to nicer looking components "easily".

I also like properties/binding, but as API, not language changes (while potentially waiting for them in 2012 for java 8): maybe similar to bean-properties or pulpcore's properties.

Which of course leads us to animations/transitions which is a must have in my book. So here, either the properties or the swing 2 api would support an easy way to animate things.

I'd like a way to support different input methods not only a mouse and keyboard, to easily do multitouch, bimanual or multimodal interactions, or games really, even though that's less interesting for business. Maybe jxinput would be enough, i never really checked.

In the same vein, I'd also wish the rendering process would be split from the event dispatch if possible, or more generically a way to get 60fps consistently for the next gen & animated UIs.

I might say while i'm not a fan of javafx script, i really like scenario (the scenegraph underlying the javafx platform): not its API per se, but because it's a part of how i'd naturally build UIs, so a lot of what i'd like is split between swing 1, the swing 2 features described here, and scenario.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

Wow, a lot more posts since I left last night. I think the number one issue that needs a vote right now is the answer to the question how do we get started on a Swing 2.0? The general options appear to include starting from scratch (with wrapping of Swing where applicable), and basing Swing 2.0 on top of Swing with major cleanups to the existing Swing API.

There will never be a full consensus I'm sure, but it has been (and will continue to be) an interesting discussion. For what it's worth, I'm not sure which side of the fence I sit on: I expect the simple approach is to rework Swing 1.0, but perhaps the better approach is to start from scratch and try to maintain a Swing-like API.

@Alex Ruiz: I would be highly surprised that this discussion lead to anything from Sun. I would be more inclined to believe that this be a community effort that may one day be accepted by Sun, but realistically probably not :)

Regardless, we aren't cutting code yet, we still have a lot of discussion to do. We have to be understanding of the scope of a Swing 2.0 project, and so whilst a number of points raised in comments are great, many just won't be feasible. We don't want to be stuck chasing a dream, we want a usable, friendly, clean, powerful, Swing-like API.

[JonathanGiles]

Auto-imported comment, original author: Aberrant (Collin) Comment posted on: January 27, 2009

Well that brings up the question "What is Swing?". If Swing is the current code, then well, that has all been released under GLP+CPE so one could fork it and move forward. If it's an ideology or way of approaching ui development then that's harder to quantify. I think a lot is possible with a fork.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

@Aberrant: I tend to agree - I think everyone agrees that a Swing 2.0 uses Swing 1.0 in some capacity. There is too much good quality code in there to ignore it. Whether components are extended from JComponent or not, there is still a lot of code in Swing that can be reused.

[JonathanGiles]

Auto-imported comment, original author: Eric Burke Comment posted on: January 27, 2009

Consistent veto mechanism. JTable, JTree, JList, JTabbedPane, and others all have different APIs when you want to veto a proposed selection change.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

@Eric Burke: Good thinking! That is a definite in my opinion.

[JonathanGiles]

Auto-imported comment, original author: Ivan Comment posted on: January 27, 2009

Is there a possibility to use the JavaFX API without this strange syntax? Just pure Java?

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

@Ivan: unfortunately I can't answer that question. But I agree, my interest is in using the Java language rather than what I consider a relatively strange JavaFX language. In addition to this, I would rather use a Swing-like programming approach (with the API being as similar as possible to Swing) rather than a brand new API. So, my vision is simple: Swing, better.

[JonathanGiles]

Auto-imported comment, original author: Dan Howard Comment posted on: January 27, 2009

I agree with everything here except the addition of Properties at the language level. Existing property support can survive refactoring - it just requires a bit of IDE smarts. This does work with JSP pages for example.

There is no good convention for properties at the language level, they can mask performance deficits in code, and they reduce readability. Grab any blop of C# code and tell me what it does without looking at other parts of the code.

Let's not make the same mistakes Microsoft made with C#.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

@Dan Howard: I tend to agree - properties are not part of my vision for a Swing 2.0. I am quite happy with getters/setters for now. I believe considerable improvements can be had in a Swing derivative without the need for properties.

Should properties come along externally due to Java 7, 8, n-1 or n, then certainly, a Swing 2.0 should make be upgraded and cleaned up to make use of this. This is the problem with Swing - this did not happen when it had the chance, and the API has become too much.

[JonathanGiles]

Auto-imported comment, original author: Larry Singer Comment posted on: January 27, 2009

There are lots of things I would like to improve in Swing, and Swing 2.0 (with a clean API) may be a good way to go about it.

I would also love to throw away the existing code implemented with Swing, but this is not an option after many person years of work. We would need a way to implement new functionality with Swing 2.0 while allowing existing functionality to continue running. We would therefore need a way to embed Swing 2.0 in our existing Swing application. (This is something JavaFX has so far failed to deliver.)

One method of doing this is to maintain backward compatibility, but I think this comes with a large cost. Another way is to build an adapter that allows Swing 2.0 components to run inside Swing containers.

There should also be the ability to embed Swing/AWT/JavaFX/SWT components in Swing 2.0 for maximum flexibility.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 27, 2009

@Larry Singer: I agree - I think some form of wrapping is important to allow some form of reuse.

Unfortunately, from the discussions I've had with people regarding Swing 2.0, the real issue is that with such a (currently) hugely scoped project, it would be difficult to develop a solution that can make it all the way through to being truly usable without some form of funding. I am trying to have some discussions around this, but I'm just a guy in New Zealand - it's really up to everyone out there reading this to push for a Swing 2.0.

[JonathanGiles]

Auto-imported comment, original author: Arek Comment posted on: January 27, 2009

+1

I'm only not sure about collections. Vectors should go, but should it be replaced by List etc. in API? I will be happy if we could use only proper interfaces as Model not collections. Maybe default implementation should accept new collections, but something like new JList(List list) should not be allowed in my opinion.

JavaFX is not Swing 2.0 but I believe this was marketing decision not technical one. When I was reading about F3 it was very much said what it will be better way to build swing application. Sun just changed mind in one point, maybe they should again.

[JonathanGiles]

Auto-imported comment, original author: lunatix Comment posted on: January 28, 2009

swing 2 must be a modern api, tailored for the future : shouldn't swing be based on a GL binding (JOGL or LWGL) to be able to have 3D effects ?

[JonathanGiles]

Auto-imported comment, original author: Aekold Comment posted on: January 28, 2009

@Jonathan how do you think, is it possible that OpenJDK guys will be interested in swing2?

[JonathanGiles]

Auto-imported comment, original author: Mass Comment posted on: January 28, 2009

"I’m not a JavaFX person yet, simply because my day job is fully Swing, and it will be for the foreseeable future. For this reason, Swing 2.0 is what I need, not JavaFX."

That is basically a non-reason. You don't want it because your employer doesn't want it for some unnamed reason...

JavaFX isn't perfect and it's possible that a revised Swing could potentially be a better fit for certain applications.

However JavaFX really has a lot of advantages, it's a very serious contender for building rich-client desktop apps or plugin-based web apps, and when proposing a new version of Swing, you really need to adress it at a little more depth than "just because".

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 28, 2009

@Mass: Thanks for your comment - I'm open to people disagreeing with me :)

To clarify: when I say my day job is fully Swing, that is because I am a full time developer who chooses to program in Swing. I am CTO of a software company, and so I choose Swing based on the fact it has been available for the life of my software, that the people who develop the software are skilled in it, and that Swing has never let the software down. Also, any outside work that I do I inherently choose Swing, because I know it so well and it works. Therefore, your second paragraph is moot - I don't choose Swing "just because", I choose it because it works, is powerful, and I have invested a lot of time to know it well. Throwing that away to instead use JavaFX just doesn't make sense to me.

The feeling from the feedback I am hearing is that many people are in the same boat - they really like Swing, and to some degree don't want to lose that when moving over to JavaFX. They feel like moving to JavaFX means that they have to throw the baby out with the bath water, and it doesn't compute :) At the end of the day, I want a cleaner Swing-like API, not a completely new one. That is my reason for a Swing 2.0 and not using JavaFX.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 28, 2009

@Aekold: That is possible I guess, but I think at the moment we need to just keep discussing what a Swing 2 means to people. I'm about to start up a forum so that discussions can be a bit easier. I'll make a new post once I do.

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 28, 2009

My daytime job is 80% swing. But I'm in doubt between JavaFX and Swing. User interfaces have become more fancy and Swing is not the best platform to add that too.

I've build an a.o. "apple menu" in Swing myself and know it is not the most practical frame to do animation in and the animations are not extremely smooth. So JavaFX certainly has merits when it comes to fancy GUIs.

I also have done some flash, so I converted a screen I wrote to JavaFX and was very pleased with the code-first approach. So JavaFX has some plusses on Flash.

But for normal administrative forms the JFX animation is overkill. So JavaFX as Swing replacement stands-or-falls with how well they will be supporting Swing alike coding. As it stands now, it is not sufficient.

However, the problem of learning a new syntax is not what is holding me back from JavaFX; it simply is not a replacement yet. But the syntax would never be a reason not to switch. We in the software business continuously have to learn new things. It took me quite some time to get the feel for JGoodies binding, more than the JFX syntax. As soon as you are at the point of "I'm comfy here, I don't want anything new", then you're on the dangerous side of the hill IMHO.

So ATM JavaFX is not a replacement for Swing. 1.1 or 2.0 maybe, but who knows. And when will it arrive? Swing 1.0 always has me working around shortcomings because of its legacy. So if people are willing to rethink the basic Swing framework and write new components, I'm in and contribute some myself.

But I would very very much advise anyone to take one day and at least try JavaFX. It is not wise to form an opinion without having tried it.

[JonathanGiles]

Auto-imported comment, original author: Christian Comment posted on: January 28, 2009

+1 for swing, from me to!

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 28, 2009

@Tbee: Absolutely. I tend to think Swing is the right API for programming enterprise software, which is where my mindset is. I like nice-looking swing applications, but I'm not looking for inconsistent, animated, 'designed' user interfaces as much as I want a nice, enterprise look, with a cleaner API underneath to make development easier and less error prone.

As a side note, Thierry Lefort has taken the opposite point of view to the one taken on this blog, and you can see this here: http://www.jroller.com/Thierry/entry/as_a_swing_developer_i

Cheers, Jonathan

[JonathanGiles]

Auto-imported comment, original author: Tbee Comment posted on: January 28, 2009

Showering always is a good way to gather one's thoughts.

Do we really want to invest our time and effort into a framework that is compatible with Swing (just like JavaFX), has a better painting logic (just like JavaFX), supports binding out of the box (just like JavaFX), and preferably does make properties and actions/events easier (just like JavaFX)... but is -in fact- competing with JavaFX to become the new Java GUI toolkit?

My beef with Swing, and the point that I was trying to push (hard ;-) ), is that the core is ok, but all the components need to be rethought and rewritten with user friendlyness in mind. So I wanted a new clean shiny J2Component and start from there. I'm leaning towards JavaFX CustomNode to be that new component...

[JonathanGiles]

Auto-imported comment, original author: Curt Cox Comment posted on: January 29, 2009

If you want to know what needs fixed most in Swing, you need to survey the other Java GUI Toolkits. Buoy has a good analysis of Swing's problems.

http://buoy.sourceforge.net/AboutBuoy.html

The hard question that isn't being addressed is who will do the coding. I would love to see a Swing 2.0 that ditches JComponent. Without doing that, you won't be able to address most of the basic flaws.

With limited resources, however, I think a much more reasonable strategy is to identify existing projects based on Swing (Spin, SwingX, GlazedLists, EventBus, BeanProperties, etc...) and consolidate them into a tested, documented, and supported whole.

Actually, just a well organized catalog of existing Swing extensions would be useful. Add descriptions, comparisons, and other useful meta data and it would be even better.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 29, 2009

@Curt Cox: I agree - there is a huge amount of support I feel for a Swing 2 that cleans up Swing, but everyone is busy with their own projects to be able to focus on it. As I mentioned earlier, and as others have mentioned to me, it is a project that really needs a few talented API designers who know Swing well to sit down and plan the improvements.

I agree regarding pulling together lots of other projects, but the end result will still be based on the current Swing API. Making a list of their functionality and availability would be a nice first step however.

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 29, 2009

Just a quick update, Danny Coward has a blog at Sun called The Planetarium. He has posted a quick blog post acknowledging this discussion <a href="http://blogs.sun.com/theplanetarium/entry/java_se_language_still_swinging&quot; rel="nofollow">here</a>. Danny Coward is a big name within Sun when it comes to JavaSE.

[JonathanGiles]

Auto-imported comment, original author: James Comment posted on: January 29, 2009

I use Swing and really like it. I don't think its all that tough to learn though there are some things that could be easier. Alot of the items that are being mentioned sound great, but I do really think that we do need more components and themes/skins/LnFs built in. Sun should live up to its commitment to Java.net and leverage the great work by folks like Kiril and Romain and many many others and throws its weight (programmers, resources, etc) to get their stuff into Swing 2.0. It should also look look at and glean the various Ajax toolkits out there and understand that if it really wants Swing to be the UI toolkit of choice, it really does have to compete against all the 'pretty' stuff out there. But that's just my 2.0 cents.

[JonathanGiles]

Auto-imported comment, original author: Patrick Wright Comment posted on: January 29, 2009

Hi

Some quick thoughts: 1- I suggest everyone take a look at: Thinlet, Pivot, Buoy, Foxtrot, Glazed Lists, et. al. to see what alternate takes on lightweight Java GUI frameworks, or solutions to Swing dev problems, are already available. Pivot in particular is a complete GUI toolkit which was started recently and is in active development. Buoy has some great ideas. You might just join one of those efforts.

2- As far as coding goes, you could save a lot of time by starting with an existing Swing codebase. There are three complete or mostly complete ones I know of as part of OpenJDK, GNU Classpath, and Apache Harmony. Just pull out the javax.swing.* packages, open in your editor, rename the top-level packages, and start hacking. If you keep a couple of Swing projects open in your IDE at the same time you could even refactor both Swing and the apps at the same time. Just choose a license you can live with.

3- I would try and contact long-time Swing developers (there are some like Jeanette on SwingX who started with Swing when it was in beta) and take an interest in their input and insight.

4- I think a good community goal is to make sure it's fun to use. Take a look at the enthusiasm around, say, Processing and Groovy's SwingBuilder. It's a practical idea to support the business market, but if you can get hackers and hobbyists interested in playing with the APIs you'll get free press, feedback, input, etc. Those folks will let you know with no hesitation when your APIs are getting complex, hard-to-use, etc. And when you hit a home run, they'll be there to cheer you on.

Thanks for starting this discussion. Patrick

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: January 29, 2009

@Patrick Wright: Thanks for your thoughtful comment. I am definitely trying to contact people who might be interested. If you know of anyone, please email them directly and refer them to this blog.

Cheers!

[JonathanGiles]

Auto-imported comment, original author: Bernd Rosstauscher Comment posted on: January 29, 2009

Hi all, For me Swing is part of my daily job and I learned to love it and to hate it. I believe having an Swing 2.0 would be a wonderful thing. There are a lot of interesting ideas here. Mikael Grev has already highlighted most of the severe problems with the current Swing implementation. We develop now for 10 years a big Java application. It has 30000 classes and 4 million lines of code. We started with Java 1.0 some decades ago. We kept it up do date all the time and currently it is migrated to Java 1.6 it uses Generics in all ways and makes good use of all modern Java APIs.

How did we manage it to keep the application alive for this long. Refactoring! Even BIG refactoring. So my advise is. Take Swing 1.0 and start refactoring. Even complete radical changes are possible with refactoring when done right. To change some APIs or to get rid of old components some times took 2 years and longer but someday you are finished.

Why not write from scratch? It is alluring. But is there only one guy around that can claim that he will do everything right straight from the beginning. Well start from scratch and plan a big Swing2.0 and in 5 years from now you will perhaps be finished and have a Swing 2.0 that will be better in some areas and some others will have problems as bad as the problems that you have now with Swing 1.0 So copy the current swing and start refactoring. Add methods and models with generics and make the old ones deprecated. Find all references to the deprecated methods and remove them one by one and you will have a Swing 1.0.1 Add Painter Support to all components and you will have an Swing 1.0.2, ...

Just my insignificant opintion.

• Bernd