Swing Application Framework Dead

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.

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.

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.

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?

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

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?

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

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

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.

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.

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

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>

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!