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