Swing Application Framework Dead

Discussion in 'Java' started by markspace, Mar 3, 2012.

  1. markspace

    markspace Guest

    We occasionally get JSR 296 (SAF) questions here on cljp. For you older
    hands, I thought I'd point out that NetBeans 7.1 has finally removed
    support for SAF. Their wizard for "Java Desktop" is gone, and it was
    done on purpose. Only the regular "Java" platform remains in the New
    Project wizard.

    So if anyone shows up with an older version of NetBeans and has a
    question, we can tell them that all support has been pulled and everyone
    finally agrees JSR 296 has bit it.

    JSR 296 has ceased to be, expired and gone to meet its maker, it's a
    stiff, bereft of life, rests in peace, if you hadn't nailed it to the
    perch it'd be pushing up the daisies, its metabolic processes are now
    'istory, it's off the twig, kicked the bucket, shuffled off 'is mortal
    coil, run down the curtain and joined the bleedin' choir invisible.

    This is an ex-parrot.
    markspace, Mar 3, 2012
    #1
    1. Advertising

  2. markspace

    Jeff Higgins Guest

    On 03/03/2012 04:52 PM, markspace wrote:
    > I thought I'd point out that NetBeans 7.1 has finally removed
    > support for SAF.

    Good, bad, indifferent? Now what?
    Jeff Higgins, Mar 4, 2012
    #2
    1. Advertising

  3. markspace

    Jeff Higgins Guest

    On 03/03/2012 09:17 PM, Jeff Higgins wrote:
    > On 03/03/2012 04:52 PM, markspace wrote:
    >> I thought I'd point out that NetBeans 7.1 has finally removed
    >> support for SAF.

    > Good, bad, indifferent? Now what?


    What did the SAF runtime consist of?
    How did Netbeans package it with an SAF application?
    Jeff Higgins, Mar 4, 2012
    #3
  4. markspace

    markspace Guest

    On 3/3/2012 6:27 PM, Jeff Higgins wrote:
    > On 03/03/2012 09:17 PM, Jeff Higgins wrote:
    >> On 03/03/2012 04:52 PM, markspace wrote:
    >>> I thought I'd point out that NetBeans 7.1 has finally removed
    >>> support for SAF.

    >> Good, bad, indifferent? Now what?

    >
    > What did the SAF runtime consist of?


    Dead stuff.

    Seriously, the JPA hadn't been actively worked on (AFAICT) for 4 years.
    I think it was pretty bug ridden. I think it was standard Java plus a
    library (.jar) you had to distribute. I don't think NetBeans did that
    part (the library) for you. JNLP and friends are kinda on you, not the IDE.
    markspace, Mar 4, 2012
    #4
  5. In article <jiuju7$t1f$>,
    Jeff Higgins <> wrote:

    > On 03/03/2012 09:17 PM, Jeff Higgins wrote:
    > > On 03/03/2012 04:52 PM, markspace wrote:
    > >> I thought I'd point out that NetBeans 7.1 has finally removed
    > >> support for SAF.

    > > Good, bad, indifferent? Now what?

    >
    > What did the SAF runtime consist of?
    > How did Netbeans package it with an SAF application?


    This was the most recent tutorial I'd seen:

    <http://netbeans.org/kb/70/java/gui-db.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Mar 4, 2012
    #5
  6. markspace

    Arne Vajhøj Guest

    On 3/3/2012 11:00 PM, markspace wrote:
    > On 3/3/2012 6:27 PM, Jeff Higgins wrote:
    >> On 03/03/2012 09:17 PM, Jeff Higgins wrote:
    >>> On 03/03/2012 04:52 PM, markspace wrote:
    >>>> I thought I'd point out that NetBeans 7.1 has finally removed
    >>>> support for SAF.
    >>> Good, bad, indifferent? Now what?

    >>
    >> What did the SAF runtime consist of?

    >
    > Dead stuff.
    >
    > Seriously, the JPA hadn't been actively worked on (AFAICT) for 4 years.


    You mean SAF??

    > I think it was pretty bug ridden. I think it was standard Java plus a
    > library (.jar) you had to distribute. I don't think NetBeans did that
    > part (the library) for you. JNLP and friends are kinda on you, not the IDE.


    Arne
    Arne Vajhøj, Mar 4, 2012
    #6
  7. markspace

    Jan Burse Guest

    markspace schrieb:
    > We occasionally get JSR 296 (SAF) questions here on cljp. For you older
    > hands, I thought I'd point out that NetBeans 7.1 has finally removed
    > support for SAF. Their wizard for "Java Desktop" is gone, and it was
    > done on purpose. Only the regular "Java" platform remains in the New
    > Project wizard.
    >
    > So if anyone shows up with an older version of NetBeans and has a
    > question, we can tell them that all support has been pulled and everyone
    > finally agrees JSR 296 has bit it.
    >
    > JSR 296 has ceased to be, expired and gone to meet its maker, it's a
    > stiff, bereft of life, rests in peace, if you hadn't nailed it to the
    > perch it'd be pushing up the daisies, its metabolic processes are now
    > 'istory, it's off the twig, kicked the bucket, shuffled off 'is mortal
    > coil, run down the curtain and joined the bleedin' choir invisible.
    >
    > This is an ex-parrot.
    >


    Maybe supperseeded by android.app.*.

    But I am not sure yet about the pros and cons
    of the android.app.* approach. It also provides
    relative access to resources such as files,
    databases and preferences.

    But I am currently facing the following problem:
    Integrating different JFrame's from different
    providers in one application experience. How
    could this be done?

    Well one could opt for heavy frameworks such
    as Eclipse etc.., drop a little bit the idea
    of a JFrame and adopt the screen space organization
    of the heavy framework and go into the lengths
    of definig a plugin.

    But if we are left alone with Swing, all that
    we have available framework wise is the following:
    - organic exit (JVM exits when all
    frames are closed and only daemon threads
    remain)

    Can SAF be considered something inbetween
    Swing and Eclipse? What other similar
    frameworks like SAF are available now?

    Bye
    Jan Burse, Mar 4, 2012
    #7
  8. markspace

    Stefan Ram Guest

    Jan Burse <> writes:
    >Maybe supperseeded by android.app.*.


    If you like to read comments regarding your
    spelling, feel free to ROT13:
    N »fhccre« vf n yvtug riravat zrny.
    N »frrq« vf n cynag bihyr pbagnvavat na rzoelb.
    Gurer vf n ireo »gb fhcrefrqr«.

    >But I am currently facing the following problem:
    >Integrating different JFrame's from different
    >providers in one application experience. How
    >could this be done?


    It all depends on details of the implementation
    of the JFrames and the target design.

    You might, for example, design the target to
    be a javax.swing.JDesktopPane. In this case,
    the former JFrames become javax.swing.JInternalFrame.

    Depending on the source design this might be
    a snap assignment or hard work. When the source
    has a proper separation between the models of
    the JFrames and the UI delegates of the JFrames,
    it's more easy: You just need to adjust the
    UI-delegate code and can ignore both its model
    and also all of the internal components (I am
    not sure about the last part).

    You also need to merge all the former
    javax.swing.JMenuBar objects into a single
    menu bar. This can be done by creating a
    javax.swing.JMenuBar in the main application
    and then passing it into the subapplications
    to be populated with menus and menu entries.

    >But if we are left alone with Swing, all that
    >we have available framework wise is the following:
    >- organic exit (JVM exits when all
    >frames are closed and only daemon threads
    >remain)


    I love organic exit and try to accomplish it
    with all my code, but I was not aware that there
    even is a word for it: »organic exit« - nice!

    But I would replace the word »closed« with
    »disposed« above. A little bit sad: We have

    java.io.Closeable

    but no

    java.lang.Disposable

    . I also would prefer »java.io.Closeable« to be
    »java.lang.Closeable«. All interfaces that can be read to
    have a general meaning should be part of »java.lang«.
    Stefan Ram, Mar 4, 2012
    #8
  9. markspace

    Arne Vajhøj Guest

    On 3/4/2012 11:27 AM, Jan Burse wrote:
    > markspace schrieb:
    >> We occasionally get JSR 296 (SAF) questions here on cljp. For you older
    >> hands, I thought I'd point out that NetBeans 7.1 has finally removed
    >> support for SAF. Their wizard for "Java Desktop" is gone, and it was
    >> done on purpose. Only the regular "Java" platform remains in the New
    >> Project wizard.
    >>
    >> So if anyone shows up with an older version of NetBeans and has a
    >> question, we can tell them that all support has been pulled and everyone
    >> finally agrees JSR 296 has bit it.
    >>
    >> JSR 296 has ceased to be, expired and gone to meet its maker, it's a
    >> stiff, bereft of life, rests in peace, if you hadn't nailed it to the
    >> perch it'd be pushing up the daisies, its metabolic processes are now
    >> 'istory, it's off the twig, kicked the bucket, shuffled off 'is mortal
    >> coil, run down the curtain and joined the bleedin' choir invisible.
    >>
    >> This is an ex-parrot.

    >
    > Maybe supperseeded by android.app.*.


    As Android is not part of JCP Java: no.

    > Can SAF be considered something inbetween
    > Swing and Eclipse? What other similar
    > frameworks like SAF are available now?


    http://en.wikipedia.org/wiki/Swing_Application_Framework#Forks_and_Alternatives

    I think RCP is by far the most widely used.

    Arne
    Arne Vajhøj, Mar 4, 2012
    #9
  10. markspace

    Jeff Higgins Guest

    On 03/04/2012 11:27 AM, Jan Burse wrote:

    > Well one could opt for heavy frameworks such
    > as Eclipse etc..

    What metrics describe the weight of an application framework?
    Jeff Higgins, Mar 4, 2012
    #10
  11. markspace

    Jan Burse Guest

    Stefan Ram schrieb:
    > You also need to merge all the former
    > javax.swing.JMenuBar objects into a single
    > menu bar. This can be done by creating a
    > javax.swing.JMenuBar in the main application
    > and then passing it into the subapplications
    > to be populated with menus and menu entries.


    And, last but not least, making the menus/menu
    entries visible depending on the focused
    subapplication.

    Something I don't need to do if I don't
    adopt the multi-document framework and stick
    to the JFrame. Which is enough for the currrent
    super application at hand.

    But I feel there could be done something
    elementary concerning menu items such as quit
    etc.. probably found in all sub application.
    Was first thinking of the following idea:

    JFrames can he marked as Daemon. When all
    non-Deamon JFrames are gone, the Deamon
    JFrames are automatically closed (this is
    what the user sees, under the hood they will
    be dispose, maybe they will even given a chance
    to ask the user for save if there is dirty
    data).

    Kind of an extension to the organic exit.
    Any framework known to implement this?

    But the above concept breaks for tool windows,
    which are not satelite to the whole super application,
    but only to some sub application. So the framework
    would need more structure than only a Daemon flag
    for the JFrame...

    Bye
    Jan Burse, Mar 4, 2012
    #11
  12. markspace

    Jeff Higgins Guest

    On 03/04/2012 09:31 AM, Arne Vajhøj wrote:
    > On 3/3/2012 11:00 PM, markspace wrote:
    >> On 3/3/2012 6:27 PM, Jeff Higgins wrote:
    >>> On 03/03/2012 09:17 PM, Jeff Higgins wrote:
    >>>> On 03/03/2012 04:52 PM, markspace wrote:
    >>>>> I thought I'd point out that NetBeans 7.1 has finally removed
    >>>>> support for SAF.
    >>>> Good, bad, indifferent? Now what?
    >>>
    >>> What did the SAF runtime consist of?

    >>
    >> Dead stuff.
    >>
    >> Seriously, the JPA hadn't been actively worked on (AFAICT) for 4 years.

    >
    > You mean SAF??
    >

    That one's my fault I snipped:
    > We occasionally get JSR 296 (SAF) questions here on cljp.

    without warning.
    Jeff Higgins, Mar 4, 2012
    #12
  13. On 12-03-04 02:58 PM, Jeff Higgins wrote:
    > On 03/04/2012 11:27 AM, Jan Burse wrote:
    >
    >> Well one could opt for heavy frameworks such
    >> as Eclipse etc..

    > What metrics describe the weight of an application framework?
    >

    A decent general purpose definition of lightweight and heavyweight,
    applicable to way more than just frameworks, is the degree of
    extensibility and configurability and flexibility built into the
    "thing". Whether that "thing" be an application framework or a messaging
    protocol or whatever.

    A lightweight system handles the easy cases, perhaps some of the medium
    difficulty cases, but can't deal with complex cases. Maybe you can't
    customize at all, or there is just way too much you have to implement
    yourself. java.util.logging is lightweight; log4j is more heavyweight.

    Java EE 5/6 and Spring are both heavyweight. A lot of Spring aficionados
    persist in wanting to call Spring lightweight: they must have some
    different definition, and I think I know what it is. Some people equate
    "lightweight" with "low barrier to entry" (ironically not true for
    Spring anyway) or "minimal configuration" (ironically not true for
    Spring anyway) or "low complexity" (ditto), but that's a confusing
    usage. I prefer the one I put forth (which I didn't invent btw), which
    is actually true for Spring, and one which they shouldn't shy away from.

    JSF, for example, is more heavyweight than a number of other web
    frameworks (certainly way more heavyweight than writing with servlets
    directly). JPA is more heavyweight than iBatis/MyBatis. In all these
    cases "lightweight" vs "heavyweight" is not a bad vs good comparison;
    it's merely a comparison of
    extensibility/configurability/flexibility/manageability etc.

    The definition carries: we can identify lightweight web servers and
    heavyweight web servers, at least side by side. We know that Alfresco is
    a "lighter-weight" CMS than FileNet P8; we know that enterprise Oracle
    is a "heavier-weight" RDBMS than Derby. Nothing pejorative about calling
    the one "light" and the other "heavy".

    Dunno about metrics, but this definition does imply that in order to do
    anything with a "heavyweight" framework you've got lots of accompanying
    stuff. The upside of this is that you can do lots of different things. A
    "lightweight" framework implies that you can't do nearly as many
    different things, or it's maybe more work to get some things done
    compared to a "heavyweight" setup, but you've got less stuff to take
    along for the ride and configure to get a given thing accomplished.

    AHS
    --
    -- Gaiety is the most outstanding feature of the Soviet Union.
    Josef Stalin, November 1935
    Arved Sandstrom, Mar 4, 2012
    #13
  14. markspace

    Jeff Higgins Guest

    On 03/04/2012 03:31 PM, Arved Sandstrom wrote:
    > On 12-03-04 02:58 PM, Jeff Higgins wrote:
    >> On 03/04/2012 11:27 AM, Jan Burse wrote:
    >>
    >>> Well one could opt for heavy frameworks such
    >>> as Eclipse etc..

    >> What metrics describe the weight of an application framework?
    >>

    > A decent general purpose definition of lightweight and heavyweight,
    > applicable to way more than just frameworks, is the degree of
    > extensibility and configurability and flexibility built into the
    > "thing". Whether that "thing" be an application framework or a messaging
    > protocol or whatever.
    >
    > A lightweight system handles the easy cases, perhaps some of the medium
    > difficulty cases, but can't deal with complex cases. Maybe you can't
    > customize at all, or there is just way too much you have to implement
    > yourself. java.util.logging is lightweight; log4j is more heavyweight.
    >
    > Java EE 5/6 and Spring are both heavyweight. A lot of Spring aficionados
    > persist in wanting to call Spring lightweight: they must have some
    > different definition, and I think I know what it is. Some people equate
    > "lightweight" with "low barrier to entry" (ironically not true for
    > Spring anyway) or "minimal configuration" (ironically not true for
    > Spring anyway) or "low complexity" (ditto), but that's a confusing
    > usage. I prefer the one I put forth (which I didn't invent btw), which
    > is actually true for Spring, and one which they shouldn't shy away from.
    >
    > JSF, for example, is more heavyweight than a number of other web
    > frameworks (certainly way more heavyweight than writing with servlets
    > directly). JPA is more heavyweight than iBatis/MyBatis. In all these
    > cases "lightweight" vs "heavyweight" is not a bad vs good comparison;
    > it's merely a comparison of
    > extensibility/configurability/flexibility/manageability etc.
    >
    > The definition carries: we can identify lightweight web servers and
    > heavyweight web servers, at least side by side. We know that Alfresco is
    > a "lighter-weight" CMS than FileNet P8; we know that enterprise Oracle
    > is a "heavier-weight" RDBMS than Derby. Nothing pejorative about calling
    > the one "light" and the other "heavy".
    >
    > Dunno about metrics, but this definition does imply that in order to do
    > anything with a "heavyweight" framework you've got lots of accompanying
    > stuff. The upside of this is that you can do lots of different things. A
    > "lightweight" framework implies that you can't do nearly as many
    > different things, or it's maybe more work to get some things done
    > compared to a "heavyweight" setup, but you've got less stuff to take
    > along for the ride and configure to get a given thing accomplished.
    >


    Thanks, I think that makes a very fine general purpose definition.

    I'm tempted to include modularity in there somewhere.
    The Eclipse RCP platform is exceedingly extensible, configurable,
    flexible and able to handle many of the difficult cases. There is a lot
    of stuff in there. But one needn't carry along all of the heavy baggage.
    Jeff Higgins, Mar 4, 2012
    #14
  15. markspace

    Jan Burse Guest

    Jeff Higgins schrieb:
    > On 03/04/2012 11:27 AM, Jan Burse wrote:
    >
    >> Well one could opt for heavy frameworks such
    >> as Eclipse etc..

    > What metrics describe the weight of an application framework?
    >


    Function points. A lightweight application framework
    has 1-3 function points, a medium weight application
    framework 10-30 function points and a heavy weight
    application framework 100-300 function points.

    The download size of Eclipse is ~200 MB (I guess with
    help texts?), my application has only ~5 MB (with
    help text). We can safely assume that the size correclates
    with the number of function points.

    So Eclipse is ~200 MB and has ~100 function points (an
    assumption for the moment). But I only need something
    with ~1 function point. So this would then do in:

    200 MB * 1 FP
    ------------- = 2 MB
    100 FP

    So everything that has a download footprint of around
    2 MB would fit my needs. So I can bundle it (stripped
    from help text eventually), with my app, and my app
    wouldn't grow that much.

    Bye
    Jan Burse, Mar 4, 2012
    #15
  16. markspace

    Jeff Higgins Guest

    On 03/04/2012 04:13 PM, Jeff Higgins wrote:
    > On 03/04/2012 03:31 PM, Arved Sandstrom wrote:


    >> Dunno about metrics, but this definition does imply that in order to do
    >> anything with a "heavyweight" framework you've got lots of accompanying
    >> stuff. The upside of this is that you can do lots of different things. A
    >> "lightweight" framework implies that you can't do nearly as many
    >> different things, or it's maybe more work to get some things done
    >> compared to a "heavyweight" setup, but you've got less stuff to take
    >> along for the ride and configure to get a given thing accomplished.
    >>

    >
    > Thanks, I think that makes a very fine general purpose definition.
    >
    > I'm tempted to include modularity in there somewhere.
    > The Eclipse RCP platform is exceedingly extensible, configurable,
    > flexible and able to handle many of the difficult cases. There is a lot
    > of stuff in there. But one needn't carry along all of the heavy baggage.


    But one needn't carry along all of the heavy baggage get a given
    lightweight thing accomplished.
    Jeff Higgins, Mar 4, 2012
    #16
  17. markspace

    Jan Burse Guest

    Jeff Higgins schrieb:
    >>

    >
    > Thanks, I think that makes a very fine general purpose definition.
    >
    > I'm tempted to include modularity in there somewhere.


    Eclipse calls its own plugin framework
    lightweight. At least the Wiki article
    says so:

    This plug-in mechanism is a
    lightweight software componentry
    framework.

    http://en.wikipedia.org/wiki/Eclipse_(software)#Architecture
    Jan Burse, Mar 4, 2012
    #17
  18. On 12-03-04 05:20 PM, Jan Burse wrote:
    > Jeff Higgins schrieb:
    >>>

    >>
    >> Thanks, I think that makes a very fine general purpose definition.
    >>
    >> I'm tempted to include modularity in there somewhere.

    >
    > Eclipse calls its own plugin framework
    > lightweight. At least the Wiki article
    > says so:
    >
    > This plug-in mechanism is a
    > lightweight software componentry
    > framework.
    >
    > http://en.wikipedia.org/wiki/Eclipse_(software)#Architecture


    Who knows who wrote that. It's also important to point out that for
    software _components_, as for some other software things, definitions of
    "lightweight" and "heavyweight" other than the one I proposed are much
    more appropriate. However, in this case I think the "lightweight" is
    associated with "framework", and very little about the Eclipse framework
    is lightweight.

    Like I suggested before, the definition of "lightweight" used most often
    these days, often by technical types who should know better, is as
    marketing-speak and it usually is meant to convey "easy to understand"
    or "not complex" or "10 minutes out of the box"...in those cases where
    it's not simply a buzzword meaning "best of breed".

    AHS
    --
    -- Gaiety is the most outstanding feature of the Soviet Union.
    Josef Stalin, November 1935
    Arved Sandstrom, Mar 4, 2012
    #18
  19. markspace

    Jeff Higgins Guest

    On 03/04/2012 11:27 AM, Jan Burse wrote:
    >
    > But I am currently facing the following problem:
    > Integrating different JFrame's from different
    > providers in one application experience. How
    > could this be done?
    >

    Different frames from the same vendor.
    Thanks for the impetus to browse.
    I found this, it's now part of my Eclipse environment.
    It's wonderful!
    <http://ubion.ion.ag/solutions/003officeintegrationeditor>
    Jeff Higgins, Mar 4, 2012
    #19
  20. On 12-03-04 05:18 PM, Jan Burse wrote:
    > Jeff Higgins schrieb:
    >> On 03/04/2012 11:27 AM, Jan Burse wrote:
    >>
    >>> Well one could opt for heavy frameworks such
    >>> as Eclipse etc..

    >> What metrics describe the weight of an application framework?
    >>

    >
    > Function points. A lightweight application framework
    > has 1-3 function points, a medium weight application
    > framework 10-30 function points and a heavy weight
    > application framework 100-300 function points.

    [ SNIP ]

    I don't think I'd want to actually want to calculate function points and
    use that as the metric, but in principle that's not a bad quantifier for
    the definition I provided.

    Loosely speaking, either by my definition or by thinking of function
    points, "lightweight" boils down to "I can't do much with this
    framework" and "heavyweight" boils down to "I can do a shitload".

    AHS
    --
    -- Gaiety is the most outstanding feature of the Soviet Union.
    Josef Stalin, November 1935
    Arved Sandstrom, Mar 4, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Big Daddy

    Java 1.2 Swing vs. Java 1.5 Swing

    Big Daddy, Apr 15, 2005, in forum: Java
    Replies:
    2
    Views:
    495
    Pete Barrett
    Apr 16, 2005
  2. mkrause
    Replies:
    0
    Views:
    669
    mkrause
    May 6, 2005
  3. lizard
    Replies:
    0
    Views:
    1,760
    lizard
    Jan 30, 2006
  4. Juan Sebastian Arbona

    Swing Application Framework

    Juan Sebastian Arbona, Feb 24, 2008, in forum: Java
    Replies:
    1
    Views:
    562
    Arne Vajhøj
    Feb 24, 2008
  5. Knute Johnson

    Swing is dead! Long live Swing.

    Knute Johnson, Feb 16, 2012, in forum: Java
    Replies:
    32
    Views:
    3,751
    Daniel Pitts
    Feb 29, 2012
Loading...

Share This Page