JavaBeans

Discussion in 'Java' started by Stefan Ram, Jul 23, 2011.

  1. Stefan Ram

    Stefan Ram Guest

    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?
     
    Stefan Ram, Jul 23, 2011
    #1
    1. Advertising

  2. Stefan Ram

    markspace Guest

    On 7/23/2011 5:18 AM, Stefan Ram wrote:
    >
    > 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?
     
    markspace, Jul 23, 2011
    #2
    1. Advertising

  3. Stefan Ram

    Stefan Ram Guest

    markspace <-@.> writes:
    >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 <>
    |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?
     
    Stefan Ram, Jul 23, 2011
    #3
  4. On 23.07.2011 17:23, Stefan Ram wrote:
    > markspace<-@.> writes:
    >> 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<>
    > |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

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
     
    Robert Klemme, Jul 23, 2011
    #4
  5. Stefan Ram

    markspace Guest

    On 7/23/2011 8:23 AM, Stefan Ram wrote:
    > markspace<-@.> writes:
    >> 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<>
    > |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.
     
    markspace, Jul 23, 2011
    #5
  6. Stefan Ram

    lewbloch Guest

    On Jul 23, 8:46 am, markspace <-@.> wrote:
    > On 7/23/2011 8:23 AM, Stefan Ram wrote:
    >
    > > markspace<-@.>  writes:
    > >> 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<>
    > > |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 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.

    --
    Lew
     
    lewbloch, Jul 23, 2011
    #6
  7. Stefan Ram

    Arne Vajhøj Guest

    On 7/23/2011 8:18 AM, Stefan Ram wrote:
    > 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, Jul 23, 2011
    #7
  8. Stefan Ram

    Arne Vajhøj Guest

    On 7/23/2011 11:55 AM, lewbloch wrote:
    > 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
     
    Arne Vajhøj, Jul 23, 2011
    #8
  9. Stefan Ram

    Stefan Ram Guest

    Stefan Ram, Jul 23, 2011
    #9
  10. [Semi-OT] Unplanned Obsolescence (was Re: JavaBeans)

    On 23/07/2011 9:12 AM, Stefan Ram wrote:
    > Arne Vajhøj<> writes:
    >> 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/


    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.
     
    Travers Naran, Jul 23, 2011
    #10
  11. Stefan Ram

    lewbloch Guest

    On Jul 23, 9:01 am, Arne Vajhøj <> wrote:
    > On 7/23/2011 11:55 AM, lewbloch wrote:
    >
    > > 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.
    >

    Nor did I limit my remarks to just that, had you not elided the rest
    of the context.
     
    lewbloch, Jul 23, 2011
    #11
  12. Stefan Ram

    Arne Vajhøj Guest

    On 7/23/2011 12:12 PM, Stefan Ram wrote:
    > Arne Vajhøj<> writes:
    >> 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/


    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
     
    Arne Vajhøj, Jul 23, 2011
    #12
  13. Stefan Ram

    Tom Anderson Guest

    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:
    >>
    >>> markspace<-@.>  writes:
    >>>> 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<>
    >>> |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
    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

    --
    I'd get more sense out of a crossed line with the Krankies
     
    Tom Anderson, Jul 25, 2011
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Hooke

    Re: Name of JavaBeans

    Kevin Hooke, Aug 27, 2003, in forum: Java
    Replies:
    1
    Views:
    362
    tommys
    Aug 28, 2003
  2. Chris Beach
    Replies:
    0
    Views:
    586
    Chris Beach
    Sep 8, 2003
  3. Henrique Seganfredo

    free swing/awt javabeans?

    Henrique Seganfredo, Nov 30, 2003, in forum: Java
    Replies:
    0
    Views:
    355
    Henrique Seganfredo
    Nov 30, 2003
  4. PZ
    Replies:
    0
    Views:
    357
  5. Gary N
    Replies:
    1
    Views:
    746
    Herman Timmermans
    Jan 3, 2004
Loading...

Share This Page