JavaBeans

[Stefan Ram]

More than 10 years ago, some people suggested JavaBeans as
software components, so that - in an IDE - Java programs can
be composed from JavaBeans.

Now, I have read someone claiming that this had failed and
that it was not used in the industry.

Can someone explain, if this is true, why it has failed?

And, if it has failed, what does this mean for program design
and those parts of Java that involve JavaBeans?

I sometimes use javax.swing.event.SwingPropertyChangeSupport,
which is a subclass of java.beans.PropertyChangeSupport.
Is this now deemed to be at risk of becoming obsolecent?

 

[markspace]

Can someone explain, if this is true, why it has failed?

I can't, because I don't think it is true. The latest EJB spec, for
example, relies heavily on Java beans.

I suspect we are missing some context here. Not all Java beans uses
have worked out. Is there a link to your source?

 

[Stefan Ram]

I suspect we are missing some context here. Not all Java beans uses
have worked out. Is there a link to your source?

Yes, I found it!

|Date: Sun, 10 Jul 2011 13:34:19 +0100
|From: Tom Anderson <[email protected]>
|Subject: Re: Spring/hibernate and JDBC
|(...)
|Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea
|dead in, like, 1998? What the hell is going on here? Is there some mad
|backwater Lost World of Java development where people are actually
|building apps by dragging icons around in tools?

 

[Robert Klemme]

Yes, I found it!

|Date: Sun, 10 Jul 2011 13:34:19 +0100
|From: Tom Anderson<[email protected]>
|Subject: Re: Spring/hibernate and JDBC
|(...)
|Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea
|dead in, like, 1998? What the hell is going on here? Is there some mad
|backwater Lost World of Java development where people are actually
|building apps by dragging icons around in tools?

<disclaimer>I do not overlook the whole Java industry.</disclaimer>

I think what this refers to is the aspect of JB to have a bean bundled
together with a GUI component and that this can be used to configure the
bean for use. I have never seen this done but then again I'm mostly
under way on server side.

If there are some examples where that approach has been used
successfully (or even used at all) I'd be interested to hear them.

When looking for reasons why there is no widespread adoption then maybe
we have to look at general issues with component based development - and
here I mean that version of CBD where you go into a store and buy
components from different vendors with the functionality you need and
then you "only" plug your application together. Of course there are a
lot of components around (some view every class as a component) but in
my experience they are usually created by one team.

Several other aspects of JB (for example: properties) are widely in use
and in fact a whole lot of other standards and tools rely on the
property accessor naming convention.

Kind regards

robert

 

[markspace]

Yes, I found it!

|Date: Sun, 10 Jul 2011 13:34:19 +0100
|From: Tom Anderson<[email protected]>
|Subject: Re: Spring/hibernate and JDBC
|(...)
|Waitwhat? Tools composing applications out of JavaBeans? Wasn't that idea
|dead in, like, 1998? What the hell is going on here? Is there some mad
|backwater Lost World of Java development where people are actually
|building apps by dragging icons around in tools?

Right. He says "Tools composing applications...by dragging icons
around." Yeah, that's dead. Except for Matisse, where GUI layout is in
fact an inherently graphical in nature, I can't think of a single useful
"drag icons around to make an app" implementation.

Maybe there's a useful tool someplace that I haven't seen, but I doubt
it. If such a thing were useful I'd think it would be popular enough
for me to notice by now.

 

[lewbloch]

Right.  He says "Tools composing applications...by dragging icons
around."  Yeah, that's dead.  Except for Matisse, where GUI layout isin
fact an inherently graphical in nature, I can't think of a single useful
"drag icons around to make an app" implementation.

Maybe there's a useful tool someplace that I haven't seen, but I doubt
it.  If such a thing were useful I'd think it would be popular enough
for me to notice by now.

NetBeans, for example, uses bean properties and other advanced
properties of beans. It's not the only program. Many programs do use
bean property-change listeners. It's not dead, just used only in the
places where it helps.

"Fail" is in the eyes of the beholder. The API is there; use it if it
helps you. There are many less-used parts of the API and people are
not calling them failures. How often do people use
'java.util.concurrent.CopyOnWriteArraySet'? Is it a "failure"?

A great majority of the "sky is falling" hyperbole in either direction
("It will save the world!", "It has completely failed!") is pure
bullshit. What even constitutes "failure" for an API element?

I would consider JavaBeans a failure if they couldn't be used for
their intended use case, not if they merely haven't been used for all
places where one might conceive they be. And look! They do work
where intended, as intended.

And as others have observed, they are used. In fact, the nearly-
universal convention of using get/set methods for properties makes
those classes that do that JavaBeans by definition. How is that a
"failure"?

There have been failures in Java. The pre-5 memory model and most of
'java.util.Date' are examples. Not JavaBeans, though.

I deem the problem with more advanced features of JavaBeans to be in
the programmers who fail to understand and use them where they'd
help. This is a problem of mediocrity in the practitioners, not of
utility of the tools.

 

[Arne Vajhøj]

More than 10 years ago, some people suggested JavaBeans as
software components, so that - in an IDE - Java programs can
be composed from JavaBeans.

Now, I have read someone claiming that this had failed and
that it was not used in the industry.

Can someone explain, if this is true, why it has failed?

And, if it has failed, what does this mean for program design
and those parts of Java that involve JavaBeans?

I sometimes use javax.swing.event.SwingPropertyChangeSupport,
which is a subclass of java.beans.PropertyChangeSupport.
Is this now deemed to be at risk of becoming obsolecent?

From your question it seems obvious that you are talking
about JavaBeans as drop and drag GUI components not as data classes.

It is definitely not widely used.

But given that maybe 95% of Java GUI's are we based and maybe
only 10% of Java desktop app developers like GUI builders, then
the potential audience is just 0.5% of all Java developers.

And if the tool support is way behind what Microsoft offers,
then even those people get disappointed.

So I think we can say that it has failed.

And I think we can blame it on lack of market and
being an immature technology (those are probably
dependent - if the market had been there then the technology
would have matured).

If you want this type of stuff then VB6 -> C# win forms -> C# WPF
has simply been the typical choices.

Arne

 

[Arne Vajhøj]

And as others have observed, they are used. In fact, the nearly-
universal convention of using get/set methods for properties makes
those classes that do that JavaBeans by definition. How is that a
"failure"?

JavaBeans in the sense of data classes with getters and setters
are certainly a success, but I don't think the original poster
is talking about that.

Arne

 

[Stefan Ram]

If you want this type of stuff then VB6 -> C# win forms -> C# WPF
has simply been the typical choices.

But then:

»The fear of .NET developers is that Microsoft's Windows
team now regards not only Silverlight but also .NET as a
legacy technology.«

http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/

 

[Travers Naran]

But then:

»The fear of .NET developers is that Microsoft's Windows
team now regards not only Silverlight but also .NET as a
legacy technology.«

http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/

I am seeing similar discussions about "native apps" for smartphones.
There are wide-ranging discussions on the interwebs if HTML5 and the new
Javascript (aka ECMAscript) will make other platforms redundant. I am
skeptical, but one should learn HTML5/Javascript as a matter of course.

I still think our traditional languages will dominate the server end.

Node.js <http://nodejs.org/> notwithstanding.

 

[lewbloch]

JavaBeans in the sense of data classes with getters and setters
are certainly a success, but I don't think the original poster
is talking about that.

Nor did I limit my remarks to just that, had you not elided the rest
of the context.

 

[Arne Vajhøj]

But then:

»The fear of .NET developers is that Microsoft's Windows
team now regards not only Silverlight but also .NET as a
legacy technology.«

http://www.theregister.co.uk/2011/06/06/windows_tablets_without_silverlight_dot_net/

I think that article is too much tabloid style.

If MS put out a newer GUI framework using HTML5/CSS/JS then it may make
XAML legacy it will not make .NET in general legacy.

I doubt that even MS at this time knows really what they will do. But
eventually they will make a decision.

And maybe the above will then become
VB6 -> C# win forms -> C# WPF -> C# XYZ
or
VB6 -> C# win forms -> C# WPF -> ABC XYZ

Arne

 

[Tom Anderson]

NetBeans, for example, uses bean properties and other advanced
properties of beans. It's not the only program. Many programs do use
bean property-change listeners. It's not dead, just used only in the
places where it helps.

"Fail" is in the eyes of the beholder. The API is there; use it if it
helps you. There are many less-used parts of the API and people are
not calling them failures. How often do people use
'java.util.concurrent.CopyOnWriteArraySet'? Is it a "failure"?

A great majority of the "sky is falling" hyperbole in either direction
("It will save the world!", "It has completely failed!") is pure
bullshit. What even constitutes "failure" for an API element?

I don't think an API element can fail. I think the only thing that can
fail is an attempt to do something. An API element is not an attempt to do
something; it might be created as part of an attempt, but it is separable
from the attempt. We can distinguish between the goal of the attempt, and
the steps taken to reach it.

The questions, then, are in pursuit of what goal or goals were JavaBeans
invented, and whether they are useful other than in that pursuit.

To start with the second question: clearly yes, they are useful. All sorts
of bits of code use setter-injected properties; dependency injection
frameworks, persistence frameworks, web frameworks, configuration
libraries, and over one billion others. The idea of the property defined
by a getter/setter pair has been very successful. You mention programs
using property change listeners; i've never come across one myself, but i
believe you.

As for the first question, well, i don't really know the answer. It's not
clear there is a single answer. Some of the people behind beans may have
just wanted a standard to build reflective injection against. But i
believe others had a vision of a world where class-grain software
components were composed into applications by graphical tools, without
needing to write code by hand. I can't point to a specification, white
paper, or manifesto describing this, but it's an idea i bumped into far
too often in the 90s for it to be a coincidence.

There are traces of it in the EJB spec: the idea of separate roles of bean
developers and application assemblers, and the rigorous separation of
interface and implementation, which has softened with time. Those are both
good ideas, which help structure single-source applications cleanly
(although the implementations of those ideas in early EJB were pretty
terrible), but i do not believe their original intent was to help
single-source developers, but to create a marketplace for components. I
believe the idea of graphical composition was part of the vision for that
marketplace.

tom