Anthony Goubard is a freelance Senior Software Engineer from Amsterdam. He has developed in Java since 1995. He has developed many softwares available at and is the main developer of the Web Services framework XINS. Anthony is a DZone MVB and is not an employee of DZone and has posted 33 posts at DZone. You can read more from them at their website. View Full User Profile

The Swing Application Framework Still in Coma

  • submit to reddit

As already said a few months ago, there is no activity on JSR 296 (SAF) and nothing much has changed since then.

Note that this JSR is a candidate for inclusion for Java 7. In the meantime Alexander Potochkin has taken the Spec lead and worked a bit on it a few months ago but for a least the last 3 months it's again quiet from Sun.
My suspicion was confirmed by Karsten Lentzsch a well-known Swing developer and one of the member of the expert group in a dicussion in the mailing list:

"I doubt that it can be included in Java 7; and I'll vote against it."

"There's no activity in the expert group, and no visible progress in the public code base. Anyway I hope that Sun will revive this JSR. At least, it would help if someone from Sun could comment what's going on."

Also this week another comment from Jean-Francois Poilpret:

"As far as I can see, there is no active development here, and this has lasted for long now. It's a very long time we didn't see Alex in here, maybe he has been requisitioned (one more) to full-time JavaFX"

"I think that now the only way to go ahead with the AppFW is to fork this project"

As far as I'm concerned and as explained once on the phone with Sun I've developed Decoration with the SAF but for all my other softwares I've decided to used my self developed framework.


Published at DZone with permission of Anthony Goubard, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Aljoscha Rittner replied on Mon, 2009/02/23 - 4:55am

I hope the AppFW wakes up ASAP :-/

Hontvári Levente replied on Mon, 2009/02/23 - 9:32am

Seeing my son learn both java and C++ I think the importance of the Swing framework cannot be overestimated. The GUI Builder in NetBeans is buggy and half baked compared to the several years old GUI Builder of Borland/Codegear Turbo C++. Matisse combined with the Swing framework is still barely usable in a similar situation. It doesn't have to be a standard but something similar must be included in NetBeans. I am afraid if the JSR is abandoned the framework eventually will be removed from NetBeans.

Hopefully JavaFX will become mature and get an easy to use GUI builder before that happens...

Eitan Suez replied on Mon, 2009/02/23 - 10:10am

if something is still not working after n years, perhaps it's time to move on.  :-)  don't rely on others to provide you an app framework.  develop as a function of your projects' needs.

Witold Szczerba replied on Mon, 2009/02/23 - 4:22pm

SAF is really bad framework. Everything is coupled, accessed by static methods, really really ugly. It is designed as bad as EJB 1/2x was. Almost year ago I was trying to discuss that topic and you know what?

2008/4/7, Bill Wohler:
>  Please also keep in mind that JSR 296 is supposed to be SIMPLE

Witold Szczerba wrote:
> 3) lets make the framework itself as modularized as possible.
2008/4/7, Bill Wohler answered:
> No, the framework was designed to be small, and as such, modularization
> would be overkill. Modularized frameworks are the worlds of the RCPs of
>> Netbeans and Eclipse as I mentioned above.

And he was not the only one accepting that terrible pseudo simplifications in the name of simplicity.

I gave SAF a try few times, but it is really useless. When you use IoC principle which leads to clean, easy to understand, de-coupled, easy to maintain, etc... code then SAF is not the way to go.

What is most sad here - there are really nice cool features I would be glad to include/integrate into my application, but well... You take all (and sell yourself to "public static..." hell) or you get nothing.

It took 3 generations of EJB to become useable, maybe SAF 2.0 or 3.0?

Geertjan Wielenga replied on Mon, 2009/02/23 - 6:11pm

I've said this before and I'll say it again (and again and again): if you need a framework anyway, why not choose one that has scaleability built into it? Isn't that the point of a framework, i.e., your application is getting slightly larger than "small" and so you want to have some typical concerns handled for you. But, if your application is getting slightly larger than "small", doesn't it follow that it's quite likely that it'll become slightly larger than "medium" too? Then, why aren't you going for a modular framework to begin with?

The only exception I can see to the above principle in the desktop Java world is Griffon: though it isn't modular, it uses Groovy, which is a fair trade off. :-)

Jean-Francois P... replied on Mon, 2009/02/23 - 6:24pm in response to: Witold Szczerba

I don't agree plainly with your statement Witold.

Although it is true that the way SAF is implemented could be much better, you cannot just say it is unusuable (or useless) just because you could not tame it so far.

SAF must indeed be simple. But that doesn't prevent other people to build a more complete framework above it (eg to add DI, dialog framework...) I have done that and I found SAF quite suitable for it.

On the other hand, it is bad that nobody seems to have commit rights to the project (or those who have are never there), hence a lot of bugs some of which many of us probably have fixed on their own "private" copy of the codebase.

Witold Szczerba replied on Tue, 2009/02/24 - 7:18am in response to: Jean-Francois Poilpret

SAF must indeed be simple.

Yes, but building it around IoC principles would not prevent it from being simple (I would say that would actually simplify it). It could be simple and powerful and extensible and.... and everything. Now it is just another bad, old fashion designed framework with cool features you cannot use if you are following good design rules. And it does not matter if it is simple or not when its global state nature makes me feel sick :)

Of course one can try hard to wrap it using for example DI framework, but it is not _that_ simple. Or maybe all I want is just it's action service (Tasks, @Action annotations, etc...) and no way - take everything or go to hell as everything is coupled. That brakes fundamental concept like the Law of Demeter. As I said - all that mistakes have been done in the past. Now we are in EJB3/Spring/Guice/PicoContainer/[many more frameworks here] era, why on Earth build such a monster now?

Is that because the majority of "desktop" application developers are just behind? When they hear "inversion of control" or "dependency injection" they are scared to death imagining some space technology, super-servers or what? Where does this aversion to clean, loosely coupled architecture originates from?

Robert Buffone replied on Tue, 2009/02/24 - 9:09am

Even after reading the JSR I'm not sure what it's supposed to accomplish.  Was this to be a standardization of something like the Eclipse RCP or Netbeans framework. 

Why would I use this, if I was asked to build a desktop application, I would need good techinical or business reasons not to use either one of these two frameworks as a starting point.  My preference would typically be Eclipse but I can see how the Netbeans framework would be appealing especially to those who like Swing.

One thing we just released at Nexaweb is a Reference framework (V1) to help people build Web-based or Desktop-based Java applications.  It is very similar to the what I think this JSR is trying to accomplish. With our customer base we have seen significant decreases in the development time of application that use our framework. So getting this JSR to completion would be a good thing for application developers.

Bob (Buffone)

Karsten Lentzsch replied on Tue, 2009/02/24 - 3:38pm in response to: Hontvári Levente

I don't quite understand why the SAF pre-draft has been included in Netbeans. Shortly after the 0.4.3 appframework version it was renamed to 1.0, in a state where the pre-draft was still buggy (it still is). And the API is less than stable, it hasn't been specified; the expert group hasn't really started a discussion, and the JSR has still not even reached the early draft spec state.

Karsten Lentzsch replied on Tue, 2009/02/24 - 3:49pm in response to: Witold Szczerba

First off, you comment on a pre-draft implementation of the JSR 296. We in the expert group are (or should be) on our way towards an early-draft specification. And there's room and time to discuss how to organize the access to features.

Next, I've found the topics and shape of the JSR 296 pre-draft work very well for the teams I work with: easy to understand, easy to handle, and it organizes their work - where many developers were more or less lost before.

Before I'd discuss in the EG how to access a 296 feature, I'd like to discuss the feature itself. How to keep Actions? Does blocking belong to Actions or Tasks? How to handle relations between Tasks? How to construct a ResourceMap? Do we want resource injection in this JSR? How to shut down an app when Tasks are running?

 And before I discuss features, I'd check whether the JSR is dead or alive. And that's where we are.

Karsten Lentzsch replied on Tue, 2009/02/24 - 4:18pm in response to: Geertjan Wielenga

The JSR 296 provides features that scale well from small to large applications. It scales as well as let's say the ResourceBundle. If you call the current appframework at a framework, than it is a scaleable and modular framework.

The JSR 296 is limited when an application consists of multiple parts provided by multiple parties and the deployer has no control (at compile time) over the complete content. That affects small, medium and large apps.

The difference between the JSR 296 and large application feature sets like the Eclipse RCP or the Netbeans modules is not primarily in the scaleability or modularity but in the code size and richness of the feature set. A 296 implementation requires about 20 classes only and aims to adress the important every day Swing tasks: life-cycle, resources, actions, background tasks, blocking.

Why not going with a large framework to begin with? Because large is too large to start with. Because small can be beauty. Because small is manageable. Because you don't want bloat. Because you want your framework to be smaller than the application. Because you want to reduce the risk for bugs in your application backbone. Because you may need to maintain the framework in a long product life cycle. Because you can't justify the time for an even larger learning curve.


Witold Szczerba replied on Wed, 2009/02/25 - 4:23am in response to: Karsten Lentzsch

First off, you comment on a pre-draft implementation of the JSR 296. We in the expert group are (or should be) on our way towards an early-draft specification. And there's room and time to discuss how to organize the access to features. [...] How to keep Actions? Does blocking belong to Actions or Tasks? How to handle relations between Tasks?

Yes, I know everything is still in alpha stage. You say there's room and time to discuss things, but I do not believe the basic stuff will change. As you said, there are problems like how to accomplish this or that, but I am complaining about the SAF base - the way the container is designed.

the JSR 296 pre-draft work very well for the teams I work with: easy to understand, easy to handle, and it organizes their work

Again, again and again. I am not saying that right now SAF is complicated or hard to understand. And again - I am far, far away from asking for change in that matter. All I ask is to get rid of global static context in this framework. Every component is coupled with global context. More than that: components, using static methods, have themselves to ask for everything they need. That makes them really hard to test and maintain as you cannot tell what are the collaborators without reading every single line of code as in every method, in every line of your component you can call whatever you want. It is like Bacic's GOTO/GOSUB hell of old days. But this is not the end. Another consequence this approach is that you cannot easily split your code into two distinct parts: the application logic and object construction logic.
So my question is: where are good design practices? How many times I will hear the same boring song: "SAF is easy, it is just easy, everyone is satisfied because it is EASY and you want to ruin that great feature." So again I will tell you: I know it IS EASY, I do not want to change that.

Richard Osbaldeston replied on Wed, 2009/02/25 - 8:13am in response to: Karsten Lentzsch

I take it the JSR board members weren't asked before the sudden unexplained jump to 1.0 and the Netbeans bundle? If so what would stop Sun from just taking that same version/bundle and dropping it into JDK 7.0 rt.jar? That's what I fear.

As I understood that change both JSR295 & JSR296 made the same jump to 1.0 overnight to make them  eligible for inclusion into Netbeans - it was regardless of any kind of fitness for purpose, stability or maturity. Indeed JSR295 was in a much worse state as it was just after Shannons rewrite and he never got around to migrating any of Scotts original unit tests. It went into Netbeans without any testing and I distinctly remember complaining bitterly about that at the time. Now my issue is more about support and the big questions over whether these JSRs are alive or should be considered shelved. I think promoting/bundling these two APIs was shabby, the the absolute lack of support in terms of bug reports, forum questions etc is unforgivably unprofessional behaviour from Sun. I think they should be supported or pulled from the product, but Sun seem quite happy to continue to do neither.

Is it at all possible to wrest the control of the JSR away from Sun? or must every JSR have a Sun lead? (that doesn't sound very open. A vote of no-confidence as it where.

I'd selfishly like the points rasied in Hans's fairwell / JSR296 unfinished business post to be addressed. I've struggled with the contrete classes, over reliance on singletons and statics in the current public implementation.Also had a hard time retrofitting and exsting app via Netbeans (support only works for new apps created via their wizard). But as you say it's only early draft quality..

For my money SwingX is in the same boat, also penciled in for partial inclusion into JDK 7, without any discussion with the contributors beforehand and AlexP also took over as lead developer. So far zero progress towards the JDK 7 goals, the promised hardware/build server nowhere to be seen and downtime on the exsting server ever more severe. Isn't the JDK 7 preview supposed to be available for JavaOne? Assuming those promises made at Devoxx where anything other than hollow ones to keep the natives sweet.

Trying not to make this personal but AlexP yet to make any posts in the Swinglabs forums. The VERY least you might expect is the same kind of courtesy Hans showed when he publicly annouced his secondment to JavaFX was going to delay progress on JSR296.. Similar to Shannons belated confession to the beanbindings mailing list.. although I find it hard to believe they can be so busy they noboy can even spare half-an-hour to post some kind of progress report.


Karsten Lentzsch replied on Wed, 2009/02/25 - 11:43am in response to: Witold Szczerba

I just commented on your statement that the SAF is bad and useless. I strongly disagree, because I found that the contrary is the case: it is useful and good.

The way how SAF features are accessed is still to be discussed, and I think there's no one who is inherently pro static accessors. For me this is a minor issue; core SAF features are already decoupled and can be used and (potentially) accessed in multiple ways: ResourceMap, ResourceConverter, ResourceManager, Task, TaskService, TaskMonitor, BlockingScope, ActionManager.

JeffS replied on Wed, 2009/02/25 - 12:56pm

I don't think a standard Swing App Framework is really necessary. In my opinion, you only really need a framework if your app has "large", or "scalable", or "complex, multi-functional" requirements. For those requirements, both NetBeans Platform and Eclipse RCP deliver quite nicely. Meanwhile, the overall client side market is moving rapidly towards RIA and Mobile (phones), and embedded. Sun is right in putting more of it's eggs in the JavaFX basket.

Anthony Goubard replied on Mon, 2009/03/02 - 4:17pm

It seems that Sun is listening as today Alex posted a new blog where he says "this project is currently #1 priority for the Swing team. We organized a little team to move SAF further"

Read the good news at:

Ashwin Jayaprakash replied on Wed, 2009/10/07 - 5:06pm in response to: Karsten Lentzsch

Hi Karsten, do you have a Blog on Swing/Java that we can follow? It would be nice to read about your work knowing how popular JGoodies became.



Carla Brian replied on Sat, 2012/06/16 - 8:38am

I hope it will be back son. I am looking forward on it. - Joe Aldeguer

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.