This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
On Sat, 23 Jul 2011, lewbloch wrote:
On Jul 23, 8:46?am, markspace <-@.> wrote:
On 7/23/2011 8:23 AM, Stefan Ram wrote:
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<t...@urchin.earth.li>
|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.
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
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
I'd get more sense out of a crossed line with the Krankies