Swing Application Framework Dead

M

markspace

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

markspace

What did the SAF runtime consist of?
Click to expand...

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

Arne Vajhøj

Dead stuff.

Seriously, the JPA hadn't been actively worked on (AFAICT) for 4 years.
Click to expand...

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.
Click to expand...

Arne
 
J

Jan Burse

markspace said:
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.
Click to expand...

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
 
S

Stefan Ram

Jan Burse said:
Maybe supperseeded by android.app.*.
Click to expand...

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?
Click to expand...

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)
Click to expand...

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

Jan Burse

Stefan said:
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.
Click to expand...

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
 
A

Arved Sandstrom

What metrics describe the weight of an application framework?
Click to expand...
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
 
J

Jeff Higgins

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.
Click to expand...

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

Jan Burse

Jeff said:
What metrics describe the weight of an application framework?
Click to expand...

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
 
J

Jeff Higgins

On 03/04/2012 03:31 PM, Arved Sandstrom wrote:

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.
Click to expand...

But one needn't carry along all of the heavy baggage get a given
lightweight thing accomplished.
 
A

Arved Sandstrom

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
Click to expand...

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
 
A

Arved Sandstrom

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.
Click to expand...
[ 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
 

Members online

No members online now.
Total: 40 (members: 0, guests: 40)
Robots: 648

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top