Talk:JavaBeans

Java Stub‑class Mid‑importance

	This article is within the scope of WikiProject Java, a collaborative effort to improve the coverage of Java on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.JavaWikipedia:WikiProject JavaTemplate:WikiProject JavaJava
Stub	This article has been rated as Stub-class on Wikipedia's content assessment scale.
Mid	This article has been rated as Mid-importance on the project's importance scale.

Layman's terms

What the hell kind of layman knows what POJO, serializable, constructors, and getter/setter methods are? I think the wording could be improved. —Preceding unsigned comment added by 128.146.248.165 (talk) 15:37, 19 February 2009 (UTC)[reply]

What the hell kind of layman looks up an article like this and doesn't at least know what a constructor is? 72.227.165.191 (talk) 04:09, 13 January 2010 (UTC)[reply]

Link to COM

I think the relation to COM that hypothetically justifies there being a link to the article needs to be made explicit. I believe a link to component-based software engineering would be more relevant. --Guillaume (talk) 12:32, 18 January 2008 (UTC)[reply]

Broken link

the 3rd link (Enterprise JavaBeans 3.0 Overview) appears broken..(I'm not confident enough to remove it myself!)

POJOs

The fact that event handling requires support classes, interfaces, and specific base classes, doesn't negate the fact that fundamentally a Java Bean is just a plain ol' object. Nor does adding interfaces, base classes, and support classes to a new class without the Java Bean conventions make the class more than any other object. 128.114.57.91 19:26, 24 October 2006 (UTC)[reply]

Move??

JavaBeans be moved to JavaBeans ??? Is there something I am missing? --so U m y a S ch 15:06, 7 May 2006 (UTC)[reply]

Support move. -- Solipsist 12:47, 24 January 2006 (UTC)[reply]

Support. The name of the technology does not have a space. – Doug Bell ^{talk•contrib} 19:04, 24 January 2006 (UTC)[reply]

JavaBeans should be moved to JavaBean, but it needs an admin as the redirect has a history. —Doug Bell ^{talk•contrib} 15:55, 8 May 2006 (UTC)[reply]

Oppose. The official name from Sun is JavaBeans. RedWolf 18:12, 2 June 2006 (UTC)[reply]
Oppose. Seconded. capnmidnight 18:16, 8 July 2006 (UTC)[reply]
Support. Other page titles are in singular, too. It's one JavaBean, two JavaBeans. Wouter Lievens 14:37, 6 June 2006 (UTC)[reply]

I've removed my vote. --Bonafidehan 16:30, 10 June 2006 (UTC)[reply]

Elaboration

This page seriously needs expansion and elaboration. As with most useless programming help pages, all it does is explain what is required for something to be considered a Java bean and how one is used - but never explains what one actually is! 68.55.218.175 16:17, 25 May 2006 (UTC)[reply]

I fail to see what further explaination of "what one is" one could make past "what is required" and "how it is used". Besides, there is a description: "a reusable component that can be manipulated visually in a builder tool".capnmidnight 18:15, 8 July 2006 (UTC)...[reply]

I absolutely agree with the original poster--imho the article makes the common comp-sci mistake of forgetting the "why" while spelling out the "how". It fails to talk about the big picture and immediately gets lost in details like method naming conventions. I read the page and went away thinking "But under what circumstances do you use them? Why would anyone dump pojos in favor of Java Beans?"--Tip: In technical articles, make sure the word because shows up in the first line. -- 193.99.145.162 18:33, 21 November 2006 (UTC)[reply]

Java Beans *are* POJOs, with a standard naming convention. As for the why, it's so you can have a "resuable component that can be manipulated visually in a builder tool." Do you need elaboration on why someone would want a reusable component? How about elaboration on why someone would want to manipulate it visually in a builder tool? You're complaining about something being missing from the article when *it's not*. If you expected something more out of JavaBeans, I'm sorry, there just isn't that much to them. capnmidnight 22:05, 30 November 2006 (UTC)[reply]

"[JavaBeans] are used to encapsulate many objects into a single object (the bean), so that the bean can be passed around rather than the individual objects.". Isn't that concept infinitely recursive ? i.e. What comes before the bean ? What comes after ? As a newcommer to JavaBeans a definately agree there is lack of context in this article. --Guillaume (talk) 13:43, 18 January 2008 (UTC)[reply]

"Isn't that concept infinitely recursive ?". Of course it is although strictly speaking, only functions deserve the "recursive" adjective. But how is that a problem? Classes can have fields whose type is a class, even the same type that's being defined. It doesn't bother anyone. Any implementation of the Composite pattern falls in your question and my counterexample (e.g. org.3wc.dom.Node). Yes it is, but it doesn't matter as the same applies to classes in object-oriented languages... Your questions apply there too; so why should there be a special lack in this article because there's no mention of what comes before or after? Anyway, I don't see any programmer in their right mind who would nest beans in beans in beans and so forth to the point that it would be a problem. I, for instance, never insert beans in beans. Amenel (talk) 13:12, 15 July 2010 (UTC)[reply]

Based on my initial research into Javaland, it would appear that there are those who are using the term POJO to mean the same thing as a Java Bean. My example comes from the sample code in "Beginning Spring Frameworks 2", Wrox Press, 2008. In chapter 2, the objects the authors describe as POJOs have all the conventions of Java Beans -- serializable, no-arg constructor, getter and setter methods. Is there something that a Java Bean has that a POJO definitely does NOT? Or are the two terms gradually merging into the same concept? In other words, I agree with the first poster. dabeamer42 14 July 2008 —Preceding comment was added at 21:12, 14 July 2008 (UTC)[reply]

A JavaBean is a POJO. But the converse is not true. Amenel (talk) 13:12, 15 July 2010 (UTC)[reply]

As to the "why", I can give an answer that reflects why I use JavaBeans in my code, whether professional or personal: just to avoid the hassle of ever growing lists of parameters in function signatures. This happens when the same parameters are passed along a chain of function calls, with or without additional parameters. Adding a new piece of information at one end of the chain requires changing all signatures until the point of consumption. Above a certain number of parameters, it's just a pain to change the signatures of all functions in the chain just so that the newly added piece of information can be passed along until it is consumed. By using a JavaBean, I just have to 1- add the field, initialized to either null or a suitable default value, and its setter/getter pair, 2- set it where it becomes available and 3- consume it where it has to be used: the set of changes and file modifications if lower. That's all... although not always feasible/sensible depending on the context. So the "reusable software components for Java that can be manipulated visually in a builder tool" definition was unknown to me (and never-experienced) until I read the article minutes ago. Amenel (talk) 13:23, 15 July 2010 (UTC)[reply]

Serializable classes

Should serializable classes have a line like "private static final long serialVersionUID = 7526471155622776147L;" I think I read that the serialVersionUID should be declared for serializable classes. Is this different for beans? Just a thought. hi —Preceding unsigned comment added by 203.197.25.11 (talk) 12:01, 6 September 2007 (UTC)[reply]

Reusability

What about a JavaBean makes it any more reusable than any other class or class hierarchy? A naive reader might think that all classes can be manipulated in a builder tool, so the article should say what the limitations of a non-bean might be. If merely adhering to the conventions makes it reusable - then please say so - and mention the use cases where it is more reusable than any other class. Might also help to say whether Enterprise JavaBeans are a subset of JavaBeans. --Hroðulf (or Hrothulf) (Talk) 08:48, 4 October 2007 (UTC) —Preceding unsigned comment added by Hroðulf (talk • contribs) [reply]

Picture

I like the example, but it would be nice to see a picture of the output. 138.162.8.58 (talk) 14:01, 20 May 2009 (UTC)[reply]

Needs a rewrite…

I think that some of this page's writers were misinformed. First of all, the article should be on the technology, JavaBeans, not on the individual software components. Second of all, the components are called beans, not JavaBeans. So, if not referring to the component model, JavaBeans, this page should be called Bean (Java). Just my opinion. --I'm Jake9 "Da' Pie!" 05:10, 17 November 2009 (UTC)[reply]