Geertjan's Blog

  • February 13, 2007

Swing Application Framework

Geertjan Wielenga
Product Manager
I've been wanting to look at the Swing Application Framework for some time. Intuitively, I imagine there's a lot of overlap between that framework and the NetBeans Platform. The central message that the NetBeans Platform presents is: "Hey, Swing applications! Come and build yourself on top of me! I provide a framework that will make your life a lot simpler, you won't need to create the infrastructure of your application... because that's what I'm for!"

Hmmm. That message sounds a lot like the message coming from the Swing Application Framework. Overloading of terms? Mixed messages? Contradictory projects? Two teams working on two projects doing the same thing? One group of people not happy with a product -- or not understanding it -- and then, instead of working to fix or improve it, making their own version of the same thing? All questions crawling in my mind, trying to find a home. However, when I look at all the info that I've seen about the Swing Application Framework, it aims to do something more modest than the NetBeans Platform. For example, in this JSR296 presentation, I find that the Swing Application Framework will not provide a docking system. So, I shouldn't expect to find an equivalent of the NetBeans API TopComponent class in the Swing Application Framework. Okay, so it is more modest than the NetBeans Platform. What/who is its target audience then? Turns out, from everything I read, that it is aimed at "small/medium apps". Meanwhile, one of the central NetBeans Platform messages is: "The NetBeans Platform is useful even for small/medium apps, because most small/medium apps eventually grow into large/massive apps. So, even if you're small, the NetBeans Platform is for you!"

Hmmm. So why would I use the Swing Application Framework? Aaah. It's simpler than the NetBeans Platform. Well, if it doesn't provide all the features that my application needs (either now or in the unforeseeable future), then the simplicity factor is not really much of a win. On top of that, is there a framework, anywhere in the world, that does not begin out simple and then grows over time into something more complex? Does the absence of a docking system right now say anything about what there will or won't be in a few years from now?

So, with this background, these tentative questions, I approach the Swing Application Framework. Clearly, my excitement at there being an application framework for Swing applications is tempered by the thought: "...but don't we already have one of those?" Maybe the idea is that once an application on the Swing Application Framework gets more advanced, it should be migrated to the NetBeans Platform? The reverse would be impossible, because the Swing Application Framework doesn't provide a modular framework and, as a result, calls into question one of the other central tenets of the NetBeans Platform, that of modular development.

I go to the home page of the Swing Application Framework, https://appframework.dev.java.net/. There I find a wonderful document, An Introduction to the Swing Application Framework API (JSR-296). It is truly a great document, describing the story succinctly and technically. I wish there were more technical documents like this one. Really cool how you're able to use annotations to mark actions, just like in web services and EJBs. Also, really cool how the code stays very close to original non-framework code, e.g., changing a JFrame to an Application is really very simple. Lifecycle management is handled by the Application class, which in some ways seems to be comparable to a NetBeans API TopComponent, except that it provides an application instead of a window in a module that installs as a plugin in a NetBeans Platform application. The small complete application at the end is also very cool. In fact, though I started out intending to download the current state of the Swing Application Framework, this document describes the framework so succinctly, at least to the point where things are right now, that I don't feel it necessary to actually play with the code myself. I can see how wizards in NetBeans IDE are going to make work with this framework even easier in the future. I can also see how tight integration with Matisse is going to be a great benefit to people wanting to make use of this framework.

However, the questions remain. For example, I don't see modular development here. In other words, how is the distribution model going to work? Say I have an update to my application. How do I distribute that? Must I redistribute the entire application to my end users? Okay, so maybe modular development is something that is useful for larger applications. But... won't my application based on the Swing Application Framework at some stage grow to a point where the NetBeans Platform would be a better basis? If so, is there a migration path from the Swing Application Framework to the NetBeans Platform? And, if so, is that migration path different to the migration path of a normal Swing application (i.e., without the Swing Application Framework) to the NetBeans Platform? And, if it is the same migration path... why will I need the Swing Application Framework at all?

Join the discussion

Comments ( 19 )
  • Tom Wheeler Tuesday, February 13, 2007

    All excellent questions... I have wondered them myself.

    I think Hans Muller was at NetBeans Day in SF last year and said that it was not intended as a competitor to the NetBeans platform. I have only read the most basic details of the JSR, but it seems that it just provides the most basic things common to all Swing applications.

    I think it would be better to use the Swing Application Framework than to just start with JFrame like you had to in the old days. I don't want to seem critical, but if you've decided to use a framework at all, why not use one that will give you those features plus window management, modular development, dependency management, integrated JavaHelp and the build scripts to put it all together -- just as the NetBeans platform does?

    Maybe NetBeans could provide a module that offers API compatibility with the Swing Application Framework. It might delegate calls to the JSR's Application class to the existing NetBeans methods. That way, it would provide an easy migration path for people that used the Swing Application Framework but found they outgrew it?

  • Sven Reimers Tuesday, February 13, 2007
    Good questions - I had the same thoughts. It seems that some JSR's are approching different aspects (already) solved in NetBeans RCP. And the conseqeunces of modularizations on an application framework will not be adressed, if only separate problems are studied in JSR's.
  • Hans Muller Tuesday, February 13, 2007

    JSR-296 will be a relatively small addition to Java SE 7 aimed at
    simplifying building garden variety Swing applications. It's
    dramatically different in scale and scope from the NetBeans Platform.
    For the foreseeable future, and as a practical matter, the two
    frameworks will have to be viewed as complementary alternatives aimed
    at different audiences. I addressed the difference between NBP and
    JSR-296 in an Artima.com article in late October last year:

    Here's the relevant bit from that article:

    The NetBeans Platform is much closer to the spirit of JSR 296
    [relative to the SwingLabs project], in the sense that it's also a
    framework within which one can build applications. However, the
    NetBeans platform is much broader in scope: In addition to
    addressing many of the issues that are fundamental to JSR 296, it
    defines a module system, a docking window system, and a very
    flexible persistence layer that resembles a file system.
    An overall goal for JSR 296 is to make it easy for new Java
    developers to get a solid Swing application up and running. A
    corollary is that the API we define has to be modest in size and
    easy to learn. The NetBeans platform requires some study and
    commitment, and NBP novices may struggle a little at first, although
    the built-in support for building NBP applications in the NetBeans
    [IDE] helps ease developers over the hump.
    That's not to say that JSR 296 doesn't envision applications built
    with modules, docking window systems, and persistence. Some of these
    features are being addressed by other JSRs that are underway right
    now. For example JSRs 277, 294, and 291 all focus on aspects of
    module support for Java SE. JSR 295, Beans Binding, supports
    automatic binding of Swing components to Java Beans that encapsulate
    application data, notably persistent application data.

    As to the specific questions about "distribution model", we're no more
    ambitious than applets, Java Web Start, and conventional installation.
    Java Web Start does support incremental updates and miserly use of
    bandwidth (check out pack200). Just like the support for modules,
    support for deployment is beyond the scope of JSR-296, but well
    within the scope of the Java platform.

  • Hans Muller Tuesday, February 13, 2007
    This question comes up periodically, so I've added it to the project FAQ:
  • Gustavo Wednesday, February 14, 2007
    > other central tenets of the NetBeans Platform,that of modular development...

    The word "Modular" really should go in the RCP book's title... ;-)
  • Geertjan Wednesday, February 14, 2007
    Thanks all for the comments. The whole story doesn't completely make sense to me, although (as stated above and elsewhere), I really appreciate the work being done by JSR296 people, as well as the module-based JSR, I think some work needs to be done on the connection between the Swing Application Framework and the NetBeans Platform. (For example, the name 'Swing Application Framework' implies that this is or will be the Swing Application Framework, as if there is no other. That strikes me as odd, since the NetBeans Platform is also a Swing application framework.

    Gustavo, I think you're right, I'm considering bringing this up in a meeting I'm having with the publisher and others soon. However, chances are that the publisher is going to vote against it because it will make the title really long and clunky. I'm definitely going to push for a front cover image that presents jigsaw pieces being put together, or blocks being assembled into a larger whole, something like that, which should represent the basic idea of the NetBeans Platform, and the central argument of the book -- modular development of rich-client application.

  • Geertjan Wednesday, February 14, 2007
    By the way, if your comment is over a certain amount of characters, it gets marked as spam. Happens to my own comments too. Then you'll have to wait until I find out about it and unspam it. Don't know why this is the case.
  • Tarun Elankath Thursday, February 15, 2007

    I completely agree with your assessment. Any "solid" swing application - which is the segment that this framework attempts to target, definitely will want the range and depth of facilities and infrastructure that are provided by the rich client platforms in existence today - Netbeans and ERCP.

    A middle-of-the-road approach is going to go nowhere. If all I wanted was to get a Swing window and a dialog running, I would simply use vanilla Swing - JFrame, et al. If I needed anything more complicated than that, it is an admission that the application UI requires engineering effort - and for that any sane developer would selectively choose and incorporate the services of a rich client platform.

    The most ironic (and amusing) thing about it is that the same mistakes are being repeated again and again - useless cruft being added to the standard library that fails to fulfill the range of REALISTIC developer need.

    Look at the answer to this question: "Why isn't session state stored with the java.util Preferences API?"

    Answer: blah..blah..Preferences API has too many limitations..blah..blah.

    Isn't that amusing? The Preferences API was introduced with the SAME verbatim as the Swing AF is being introduced today - limited in scope and scale to serve the needs of small-medium "solid" applications that need state saved. Unfortunately, it was so limited that it now fails to serve the need of another limited framework being pushed into the JDK that also wishes to serve the need of small-medium "solid" swing applications.

    (and lets not even get started on the problems of standard/non-standard/common logging toolkits..)

  • Jesse Beaumont Thursday, February 15, 2007

    I don't really understand your concern fully. You quite accurately identified a number of ways in which Swing Application Framework offers new and innovative features (annotations for example, as well as an Application context) that are lacking in Swing and some of which are lacking in Netbeans. Given that it is intended to provide a simple "leg up" for people writing swing based applications it wouldn't make sense to provide it as part of Netbeans because the NB RCP is simply too big. There's too much to learn about nodes and modes, and file systems and options and all the plethora of APIs that are available.

    I think the much more sensible and beneficial course of action would be to refactor the Netbeans APIs to bring them into line with the swing application framework. Surely, Netbeans could be considered a widening of scope and signficant extension to the JSR-296's initial intentions?

    This would do a number of things:

    1. It would give people a clear escallation/migration path from simple swing, to SAF to a fully fledged platform because each would simply be an extension of the previous. It would greatly lower the barrier of entry to using the Netbeans RCP.

    2. It would make the Netbeans RCP easier to use by virutue of offering the same features as the JSR-296.

    3. I haven't looked in detail but I would assume that it would simplify the conversion of JSR-296 based applications to Netbeans modules.

    Now clearly that work is no small feat, refactoring all those APIs. However, if Netbeans really does provide all the features currently provided by the JSR-296, why not provide a Netbeans based implementation of the specification? Or even a bridge between the RI and the Netbeans code?

    Then we're talking about a collaboration which results in a sum that is greater than the parts, instead of trying to figure out which framework is "better" or why they both exist in parallel.

  • Geertjan Thursday, February 15, 2007
    Tarun, since we agree with each other, there's not much I can say in response to what you've written here, other than to agree with you. (Are you in India, by any chance? If so, I hope to meet you sometime since I'll be there from this weekend until a month from now.) However, I have to admit that I'm a big fan of the Preferences API (I've blogged about how cool it is to use that API within the context of a NetBeans module. In fact, in 6.0, we will have an NB-based Preferences API that will simply store preferences in the NetBeans user dir instead of wherever the JDK puts it with the Preferences API.) In general though, I find the 2nd paragraph in your comment right on the money.

    Jesse, yes, in a perfect world, the best of both these approaches would be merged into one. However, the world is not perfect and, honestly, I don't see the NetBeans Platform being an extended implementation of JSR-296 in the very near (or distant) future. I would be very happy to be proved wrong, though.

  • Geertjan Thursday, February 15, 2007
    PS: Jesse (and anyone else), how would you react if NetBeans, in some upcoming release, would provide support (such as project templates and file templates and other u.i. support) for BOTH the Swing Application Framework AND the NetBeans Platform? So, for example, you'd be able to create 'actions' for both frameworks. In other words, you would need to choose which framework you want to use -- either the "Swing Application Framework" or the other Swing application framework, the NetBeans Platform. Interested to know what you would think if you were to see support for both of these. And any kind of response is acceptable.
  • guest Monday, June 23, 2008

    Well, if it doesn't provide all the features that my application needs (either now or in the unforeseeable future), then the simplicity factor is not really much of a win.

    Anything is a win if it

    1) provides something (of quality) that you'd have to write yourself.

    2) is simple enough to use on its own without dragging the kitchen sink in with it.

    I am writing a complex Swing end0user application. Am I using the Netbeans framework? No. OMIGOD ! Why not??? Because-

    Netbeans itself is slow. To use the Netbeans framework, I'd have to prove to myself that that slowness is not a inherent property of the Netbeans framework. That means I'd have to understand the framework almost as well as its authors. But wait a minute, I thought using the Netbeans framemwork was supposed to SAVE me time and effort.... maybe later....

    Netbeans, while not specifically ugly, doesn't have that, how shall I say, je ne sais qua , that certain something, that, for example Mac apps have. If I wanted a Soviet-realism-style (oh...OK...that was too mean....) utilitarian interface that the suits would approve of, I'd consider it, but I don't. I REALLY don't want that at all.

    So to use NB, I'd have to prove to myself that I can easily escape that LAF. I might find a counter example which would serve as a sort of existence proof, but, I am going to ask myself- what is this going to cost me in terms of the learning curve?

    Now consider the Preferences API. What a nice thing! No big learning curve. Works for my application just right. Plug (into my app) and play... no monstrous dependency chain.

    Does it have limitations? Does NB?

    I hope NB just takes off and does really well. I would love to contribute to it. I'd even settle to understand it well enough to use it as a framework . I am reading Rich Desktop Application... a little foggy about the modules thing....

  • Geertjan Monday, June 23, 2008

    "Well, if it doesn't provide all the features that my application needs (either now or in the unforeseeable future), then the simplicity factor is not really much of a win."

    Couldn't agree with you more, About your other points: you're making it sound as if you're the very first person who is thinking about creating applications on the NetBeans Platform. Go here for several examples that show the contrary:


    You also are concerned about NetBeans IDE being slow. You don't seem at all interested in finding out whether there may be something wrong with your particular installation of NetBeans IDE, rather than NetBeans IDE itself being slow. I can tell you that for me, NetBeans IDE is faster than Eclipse. I use both and Eclipse is definitely slower. If you'd like to investigate why NetBeans IDE is slow for you, write to nbusers@netbeans.org with a description of which operating system you're using, which version of the JDK, which version of NetBeans IDE. Right now, without that information, it is completely impossible to help you, assuming you want help, which is unclear, since you're quite happy assuming that NetBeans is slow. Every release of NetBeans has seen significant improvements in performance, 6.1 in particular. Are you on 6.1?

  • guest Tuesday, June 24, 2008

    Geertjan said"

    You don't seem at all interested in finding out whether there may be something wrong with your particular installation of NetBeans IDE, rather than NetBeans IDE itself being slow"

    Hi Geertjan. Actually, I am on the nb mailing list already and I do trouble shoot the slowness using information there. I am using 6.1 . Athlon pretty fast chip as of last year, 4 gigs of RAM.. but it's OK, I am NOT complaining about NB.. that's wasn't my intention in that post.

    Really, I was trying to help connect developers of NB with the internal thinking process of a candidate consumer of the NB framework. When you work on something and you think it's great, there's this mystification about why everyone doesn't share your view, right? I know there is for me. It's just human nature and a lack of information- information about why someone made the decision the did; what were they thinking and why didn't they see things the way I so clearly see them?

    In this case, I was a candidate for using NB. The reason I chose not to were as I listed. Am I a bad candidate user? Am I not doing my due diligence with respect to investigating this wonderful and free technology that many people smarter than me have labored mightily over? The thing is, what would it matter if that did describe me? Suppose I'm an idiot. That actually doesn't matter if I am a representative idiot of all the other idiots "out there" who constitute most of your potential users. We idiots are called your "market". Every producer's job is to meet the market. My goal was to give you feedback as to why I chose not to use your product- in some circles, that's R and D and marketing gold. We don't punish those people where I come from... we send them free stuff and big thank-you letters when they bitch about what they don't like. In my case, I just wasn't bitching; not at all.

    NB is on my machine for a reason- I would love to have an OS development environment I can understand enough to tweak and contribute my tweaks to. That's not happening anywhere else that I know of, certainly not with Eclipse (ha!), and certainly not with IntelliJ, the IDE I use currently.

    The IDE that's easiest to understand, gets the most contributions. The IDE that gets the most contributions, becomes the best over time. The IDE that becomes the best, wins.

  • guest Tuesday, June 24, 2008

    G said:

    "Couldn't agree with you more," replies : that's because I was quoting you to rebut LOL... I probably should make that clearer. Actually, I don't agree with your statement, which was for reference's sake:

    "Well, if it doesn't provide all the features that my application needs (either now or in the unforeseeable future), then the simplicity factor is not really much of a win."

    I just disagree.. if it does something small and self-contained well and efficiently, then it's a win. The more little things like that I can find, the better. The implementation of 296 that you linked to, actually, that looked good to me and made a lot of sense. I haven't looked at it too hard yet, but it motivated me to do so just because it was offering me things I had to work on anyway. That's a big win to me.

    I can't recommend your Module manifesto to in your java desktop book enough to people.. it's really great. I would like to see some further elaboration of the module concept that is independent of the NB implementation at the design level. To me, that's another candidate for a integrating into the JSR 296.


  • Geertjan Tuesday, June 24, 2008, please state your question and what you would like me to do to help you.

  • rgoodwin Monday, August 25, 2008


    Maybe the bias against the NetBeans Platform is because:

    \* NetBeans takes ages to start, so one is expecting a custom NB platform app would take as long too.

    \* The NB platform screenshots page suggests the platform is better for developing document-oriented applications. Even the bare bones app is providing unwanted options that would need disabling, e.g. favourites, properties, toolbar options.

    Perhaps you can comment on whether these perceptions are misguided?

    Many thanks.

  • rgoodwin Monday, August 25, 2008

    When comparing the two frameworks consideration is needed of the time investment converting a non-framework Swing app to being framework based.

    It would obviously be quicker to convert an app to being based on the S.A.F, as a lack of features means less to learn? And for long term maintenance, would surely be easier to train new Swing developers joining the project to use S.A.F than the NB platform ... an important consideration.

    What would be helpful is an understanding of how the NB platform could pay off longer term to make up for what appears to be initial complexities, constraints, and the difficulty finding developers experienced with it?

    Many thanks Geertjan.

  • Geertjan Monday, August 25, 2008

    rgoodwin, NetBeans is taking less and less time to start, wait and see with 6.5 for further speed up there. In addition, though, it depends completely on the features you add to the NetBeans Platform and how well you do so. If a lot is done at start up of the application, rather than at the point where the features are needed, then start up time will be slower. Secondly, there are MANY non document oriented applications on the NetBeans Platform. Have a look at 'blueMarine' for example, which is a Photo workshop application or 'jFugue Music Application' which is about music. yes, the NetBeans Platform offers a lot more features than the Swing Application Framework, therefore it takes longer to learn it but the rewards are much more significant. For example, if you want a window system, you should forget about the Swing Application Framework.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.