Swing Application Framework Dead

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

[Jeff Higgins]

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]

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

[markspace]

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.

[John B. Matthews]

In article <jiuju7$t1f$1...@dont-email.me>,

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>

[Arne Vajhøj]

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

[Jan Burse]

markspace schrieb:

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

[Arne Vajhøj]

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

[Jeff Higgins]

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?

[Jan Burse]

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

[Jeff Higgins]

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.

[Arved Sandstrom]

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

[Jan Burse]

Jan Burse schrieb:

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

That single standing frames are not dead can
be seen when looking at modern browsers. If
I look for example at Seamonkey I see the
following separate frames, besides the browser
window:

- Mail & Newsgroups
- Composer
- Addressbook
- Download Manager
- Add-on-Manager
- Datamanager
- Java Script debugger
- DOM Inspector
- What else?

Bye

[Jeff Higgins]

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.

[Jan Burse]

Jeff Higgins schrieb:

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

[Jeff Higgins]

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

[Jan Burse]

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_%28software%29#Architecture

[Arved Sandstrom]

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

[Jeff Higgins]

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>

[Arved Sandstrom]

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

[Arne Vajhøj]

On 3/4/2012 4:20 PM, Jan Burse wrote:
> Eclipse calls its own plugin framework
> lightweight. At least the Wiki article
> says so:
>
> This plug-in mechanism is a
> lightweight software componentry
> framework.

Every heard a car sales guy call the car he is trying
to sell you for "stylish", "good value for money",
"high quality" etc.?

:-)

Arne

[Arne Vajhøj]

De facto:

lightweight = our product
heavyweight = competitors product

What it should be:

You have already gotten a couple of suggestions for:

weight = level of functionality = level of complexity

I am not sure that this "absolute" measurement is
what people typical see as semantics.

I think that a "relative" measurement fits better:

weight = level of functionality or complexity provided / level of
functionality or complexity necessary to support

Let me clarify with an example:

I consider a Java library with methods implementing
10000 mathematical function with no dependencies to
be lighter than a Java component exposing only 3 methods that require:
* an EJB container
* a message queue
* an Oracle database (due to some PL/SQL SP bing used)

Arne

[Arne Vajhøj]

That is what modularity provides.

Arne

[Jeff Higgins]

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

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

Does not yet exist yet to my knowledge.

Very lightweight.

Abstract Application Annotations

Requires only a builder on the development platform.
Develop an application by writing annotated interfaces.
Declarative configuration using (xml?).

@PackagingImpl
interface IApplication
{
@PlatformImpl
void launch(String[] args);
}

@PackagingImpl
interface IPlugin
{
@Uninstall
void install();

@AsService
void start();

@Site
void update();
}

@Persistance
@Typed
interface IData
{
void create();
void retrieve();
void update();
void remove();

}

[Lew]

Arne Vajhøj wrote:

I tend to agree with Arne's characterization of the terms, and Arved's.

I value Arne's view because it's rooted in ops - "operations" - the area of
build, test and deployment that tends to be messy and labor intensive.
Big-iron shops devote a lot of manpower (i.e., money) to people just running
the systems. The more you mix frameworks with each other, like the app server
with message queues with database with stored procedures with probably JPA and
JMX present in abundance, the more you have to manage to get everything to
play nicely together.

This notion of weight pertains to the programmer, too. It's not all on ops'
shoulders. You work on, say, a JSF application with some Ajax magic and
various auxiliary frameworks for authorization levels in the front end, and
even within just that layer the interactions create effort and careful thought
to manage properly. Similar dangers pertain in the deeper layers - JPA even
within its own universe requires simple idioms to stay light; its dark
corners, exploited fecklessly, can radically complicate analysis of consequences.

An intuitive sense of the integral of (labor times intensity of attention)
over time is what I think of as "weight" in a system.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[markspace]

On 3/4/2012 1:20 PM, Jan Burse wrote:

> Eclipse calls its own plugin framework
> lightweight.

Ah yes. And we all always believe a company's advertising literature,
right?

[Jan Burse]

What if I want to decide whether my JFrame
is a deamon or not at runtime?

Jeff Higgins schrieb:

[Jeff Higgins]

On 03/05/2012 02:38 PM, Jan Burse wrote:

>> Abstract Application Annotations

> What if I want to decide whether my JFrame
> is a deamon or not at runtime?
>

Shrugs, I'm sure the unknown development team hasn't worked out all the
details yet. :|

[David Lamb]

On 04/03/2012 5:15 PM, Arved Sandstrom wrote:
> 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".

In ancient times a lightweight/heavyweight meant "done within the
program" vs "done by invoking the operating system, as in threads vs OS
processes, and Swing JComponents vs AWT components. Something could be
both complex and lightweight back then. I suspect you're right that
these days it has become yet another equivalent of "I want you to think
it's better than other people's stuff."

[David Lamb]

On 04/03/2012 8:55 PM, Arne Vajhøj wrote:
> I think that a "relative" measurement fits better:
>
> weight = level of functionality or complexity provided / level of
> functionality or complexity necessary to support
>
> Let me clarify with an example:
>
> I consider a Java library with methods implementing
> 10000 mathematical function with no dependencies to
> be lighter than a Java component exposing only 3 methods that require:
> * an EJB container
> * a message queue
> * an Oracle database (due to some PL/SQL SP bing used)

An excellent suggestion, but if "marketing" ideas have captured
light/heavy already, we might need a different pair of terms (until they
capture those, too).

[Jeff Higgins]

<http://openjdk.java.net/projects/jigsaw/>

[Jan Burse]

Jeff Higgins schrieb:

Annotations, well, they should
give information to tool chains.

Of course we can try to turn every
framework into a tool. (Also a
kind of business model)

But this doesn't make the resulting
artefact more lightweight.

You will have as a result:
- the framework
+ the annotation definitions (for Java)
+ the annotation processor (at runtime
eventually, so that there is no real
tool step)

And then you loose flexibility, in
case the framework gets locked away
from the end-user (the programmer).

Bye

Bye

[Arne Vajhøj]

I don't think we really need new terms. When one use heavy/light
it is most likely to marketing and/or managers anyway.

Arne