The SAF is dead, long live the AF?

After attending the sessions at JavaOne, and in the time leading up to it, it has become clear that poor old Alexander Potochkin is overworked. In all, he leads the technical side of the Swing team, developed the JXLayer library (which is integrated in Java 7 as JLayer), is one of the people involved with SwingLabs, and also is the leader of the Swing Application Framework (SAF). There is more that I probably don’t know about.

I don’t mean to be rude to Alex, he is a cool guy who is doing a great job with a great team (I met a number of them at JavaOne, and they all assure me they are coming to New Zealand for a sunny holiday 🙂 ). I just can’t imagine he can properly do all of these jobs without a project falling by the wayside. It is my opinion that, given current circumstances, it is the SAF that is missing out on Alex’s attention. Or, if he is giving it the necessary attention and time, he is failing to get the necessary community feedback to see it through to completion.

The other issue is that it is impossible to create a SAF that’ll please everyone. There is simply too much Swing history and convention to get past. There was no pleasing the people at the SAF BOF at JavaOne, and the questions Alex was asking were trivial (e.g. do you want @Action or to simply write ActionListeners manually?). In addition, a number of people were unclear of the scope of the SAF. People were wanting docking frameworks, validation, beans binding, etc. The response was always that SAF does not currently intend to support any of these requests.

The SAF is going around in circles. How can it get out of its funk? As one person suggested in the BOF, it needs an expert group to drive it forward. Personally, I would be very careful in suggesting this. It is important that the expert group be tasked with just the pragmatic development of a SAF API. It should try to do this rapidly and clearly document the API and the reasoning. After public discussion, this should be the API that is implemented.

Right now, if the SAF project doesn’t pull finger, sort itself out and take ownership of the public discussion, it is heading towards the junk heap. If that happens, I imagine there will be a jointly developed JavaFX and Swing application framework to be developed in it’s place. This framework will fill the gap that is in the JavaFX niche, and will as a by-product also support Swing. It will be developed by people who can get past the politics of developing an application framework, which may entail reduced public consultation, and instead the development may be sprung on a somewhat unsuspecting public.

Of course, this may not be bad – look at how old Swing is compared with JavaFX. JavaFX is still at the stage of its life where standard approches are still being defined.

So, what’s it going to be – we get behind Alex and help progress a Swing-centric application framework, or we wait for that to fail and a JavaFX/Swing application framework to rise up behind it? As always, comments are welcome.

19 thoughts on “The SAF is dead, long live the AF?”

  1. If JavaFX is the future – lets cut to the chase – work on the JavaFX Application Framework.

    It’s taken 10 or more years to get to the point of an incomplete definition of a framework for writing large Swing apps, (despite there being more Web App frameworks than stars in the sky).

    Lets get in on the ground floor and start now to layout the right foundation for doing Useful Things(tm) in JavaFX.

  2. The need for SAFs has always eluded me. Emulating the mess of the Web world is hardly a good reason for one. If you need something large and robust, Netbeans and Eclipse provide excellent RCPs. If you need to maintain Window state and preferences, well, it’s not exactly rocket science. If something has to drop, SAF would be my candidate too over something truly useful like JXLayer.

    1. @Alex: Fair point. I’ve never used an application framework either, but then I’d consider myself an expert developer who has been developing GUI’s long enough to know how to do what I need.

      The question is what should a new developer expect for a GUI API? Anything to make their lives easier should be appreciated, and will certainly increase adoption of the toolkit.

      To be fair, JLayer is now in JDK7, so there is little likelihood that it’ll be dropped now.

      1. I take the slightly confrontational point of view that “you must be this high” to write good desktop code. A new developer should do what we all did, study. There should be lots of good example code and I even support a VM flag to enforce EDT thread safety the way Substance makes mandatory.

        EDT issues are likely to be the biggest new developer gotcha and I’m not sure that an SAF would actually alleviate that at all. What we don’t need is another declarative XML framework for UI which is what a lot of developers actually mean by “framework”.

        1. “You must be so high to use this solution” is the reason why there are 1000’s of VB apps, and so few Swing ones.

          Let’s get down off the mountain and consider the masses. Ivory towers have done nothing for Desktop Java.

        2. Being new to Swing but not at all new to Java, I have to say this is really not true!

          There are hundreds and thousands of books and websites with information on each and every swing wideget and control and how to control every details of them – it’ll be probably very easy to find out how to handle each single pixel of your screen to be 150% perfect location and color.

          But when you’re starting, getting a screen layout completely right might not be what you want in first place – at least I want to know how I should start with a proper architecture – I can set the details of presentation later. But fixing an architecture that is broken from the start can be hard.

          So, there is actually a big lack on information and examples about how to build a Swing application with a good architecture – and SAF comes to the rescue at leat a bit – without having to start using a large framework like the swing/netbeans/Eclipse RCP’s.

  3. How many quality, commercial VB apps are there? I’d argue VB adoption has nothing to do with application frameworks but rather:

    – tooling support.
    Netbeans/Matisse is good, but still could use a lot of improvement. And it’s still not up to VB ’98.
    – ease of deployment. WebStart is still awful, Applets aren’t any better though they’ve improved slightly. VB -> .exe in one click. Now that’s deployment.
    – if you must use WebStart, can we get rid of that hideous “Warning – Security” dialog that will scare novice uses off like rabbits and replace it with something a little more elegant, or provide an API so we can provide our own consistent UI for it
    – Split the rt.jar, make is easier for us to bundle the JRE with our apps. I’ve got mine, JRE 1.6_13 to under 9MB, but I have to use a lot of tricks to do it and it’s still bloated because rt.jar has a log of stuff I don’t need.

    If you want to focus on something, focus on the above. That’s what will really make Swing on the desktop, instead of just making it easier to create simplistic apps.

    1. PS.

      Since we’re talking JavaFX in the other thread, how about Oracle/Sun getting out of our way and finally delivering us Swing developers a proper multimedia API. All the goodies are there in the JMC but us desktop developers aren’t allowed to use it in non-Web hosted apps. Appalling.

  4. Alex, I agree with you about “you must be this high”, but compare the state of JEE documentation on web with Swing one. On SUN’s tutorial we have not one but two medium-to-big example applications. We have JEE Blueprints. JEE Patterns. What we have for Desktop? How to make a Duke waving applet. Using a JComboBox. All the swing books i’ve seen mostly deals with how to use the components, show the API, etc. I’d like to see Blueprints. Best Practices. Sometimes RCPs are just overkill. Example aplications (and no, temperature converters with one JPanel are NOT example applications). I’ve been trying to make a CRUD-like application for some time now and no matter what I do I keep thinking it’s a bit of mess and spaguetti code. Maybe I’m just too used to Web development(4+ years) but that’s what I feel, and most desktop developers I know feel too.

    1. I’m all for documentation, etc…, just don’t see how any of the issues you address will be solved by an application framework. FWIW, has lots of tutorials(well, at least one), on building Swing CRUD apps. Books like Swing Hacks and Romaine Guy’s Filthy Rich Clients book goe way beyond components.

      1. Well, maybe a framework can encapsulate the best practices or show then. JEE does exactly that through Patterns. Either way I’d be very very happy with more Docs. I’ve seen tutorial(s), and they don’t seem to elaborate much on best practices or design.
        I’ve checked Swing Hacks and Filthy Rich Clients, but those go the other opposite showing how to use Java2D to create custom controls and fluffy things, which also doesn’t interest non-RIA people. Also, now JavaFX is there for those needs.

    2. +1 Agree, we need more practical examples and good practices.

      Another bunch of questions:

      Swing is dying ? (see the recent answers for Swing questions in Java ONE)

      JavaFX usage is growing fast enough to developeres shift to this technology ? (everyone like the buzz)

      The relation with Swing and JavaFX is like in .NET world ? (Windows Forms (the old) and WPF (the new tech)

    3. What about the translation to English of the book I wrote in French about Swing application development?
      500 pages of good practices describing the creation of Sweet Home 3D, a nice and successful Swing / Java3D application of the real world. 😉

  5. My opinion:
    I think desktop apps have too many different contexts and complexities. Also, currently there are too many application already running in the wild not using SAF. Which makes us assume that new comer’s should use it and old timers may want to migrate. For new comers they may not know about it. For old timers they may not likely migrate to the new way.

    * Don’t put it in the JRE, maybe the JDK (separate jar, like jee.jar)
    * If its not an RCP framework rename it to Client Application framework or knock off the word Swing.(AF)
    * Put it into the Java App Store as an approved lib as an option
    * Stop new development until the community gets involved.
    * Wait for project Jigzaw?

    My views and opinions change from month to month.


  6. this is an interesting post. In my JavaOne technical session about SAF/FEST I explained why there is room for a Swing Application Framework (in my point of view of course), and discussed the recent activities and development. Have you been there?

Comments are closed.