This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
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)
I am just starting to learn Java and installed NetBeans 7 and don't know what a constructor is. Why would a layman know? I get statements in tutorials (from NetBean.org site) that say "put xxx code after the constructor" without showing the code of the constructor so I know where that is. 24.23.254.32 (talk) 03:31, 12 November 2011 (UTC)
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)
I agree 24.23.254.32 (talk) 03:17, 12 November 2011 (UTC)
the 3rd link (Enterprise JavaBeans 3.0 Overview) appears broken..(I'm not confident enough to remove it myself!)
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)
JavaBeans be moved to JavaBeans ??? Is there something I am missing? --soUmyaSch 15:06, 7 May 2006 (UTC)
I've removed my vote. --Bonafidehan 16:30, 10 June 2006 (UTC)d
I moved the article (back) to JavaBeans, because that's how it's called officially. The mindless application of some rule that requires the singular for the title of an article would otherwise also require, e.g., Strut, JavaServer Face, and, for that well-known Microsoft operating system... Window. It just makes no sense that way. RFST (talk) 18:31, 22 January 2012 (UTC)
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)
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)
As a developer with experience mostly in .NET/C#, I find this article too vague as well, probably because it is lacking sufficient context and depth. First, it sounds to me that an important high-level implication of the JavaBean convention is that initial state is set not via constructors but via setters (which has implications for dependency injection). This is not explicitly mentioned, and might be obvious to someone who has actually built something with them, but is not immediately apparent from a cursory reading. Further, a technical justification should be given for each of the individual JavaBean requirements. Second, the phrases "manipulated visually", and "builder tool" are far too amorphous, yet they are supposed to suffice to explain the existence of JavaBeans. In what ways are JavaBeans manipulated visually? (As structural class diagrams? Couldn't source code be considered a visual representation that can be manipulated? Should this be reworded as "manipulated graphically"?) What are the advantages of visual manipulation that JavaBeans ultimately support? (Complexity management? Diagram construction to enhance documentation and communication? Rapid prototyping? Reduced learning curve of Java?) What "builder tools" are we talking about? (Eclipse? IntelliJ IDEA? javac and ant are "builder tools" but do they support the referenced "visual manipulation"? Do these builder tools inherently know what qualifies as a JavaBean through static code analysis? Is reflection involved in any of this?) Third, are JavaBeans standard practice? (Are they coming into or going out of favor with mainstream developers? With leading-edge developers?) Fourthly, how do JavaBeans relate to other technologies or patterns? (Are they used in distributed computing? Do they support component-proxying? What is the relationship to Enterprise JavaBeans?) Lunalot (talk) 17:10, 28 July 2011 (UTC)
To my knowledge boolean properties are capitalized the same way as other types. Compare Sun's JavaBeans spec [[1]] and the java.beans.Inspector.decapitalize(String) method. - leo 03 August 2012 — Preceding unsigned comment added by 80.218.115.95 (talk) 22:05, 2 August 2012 (UTC)
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)
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)
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)
"A Bean obtains all of the benefits of Java's "write once, run anywhere" paradigm."
Any code written in Java enjoys this benefit (on most OS's). This benefit is not specific to beans. — Preceding unsigned comment added by 217.37.69.169 (talk) 15:53, 29 May 2012 (UTC)
When were JavaBeans invented? Have there been any major modifications to the concept since then? RenniePet (talk) 02:25, 23 July 2013 (UTC)
The first sentence states "JavaBeans are classes that encapsulate many objects into a single object (the bean)." I believe this is a really bad thing to say for three reasons:
There is no need for multiple objects to be involved in a JavaBean. A perfectly good example (though of little use) is
import java.io.Serializable;
public class JBExample implements Serializable {
public JBExample(){}
}
Also, though a class may "encapsulate many objects," it is usually the instances of classes one is more interested in. The encapsulation (or not) of objects directly in a class is irrelevant for being a bean.
Finally, if the actual intent was to speak of instances of a class: It is not only unnecessary to encapsulate many objects, it is also not sufficient to do so. Java objects may well encapsulate many other objects, but they need not be an instance of a JavaBean class to do so.
Randallbsmith (talk) 19:02, 10 March 2016 (UTC)
I kind of feel like the advantages/disadvantages sections should be rewritten in a way that is more neutral. I don't feel it is neutral to label something as an advantage or disadvantage because theoretically, an advantage to one person could be a disadvantage to another. Somebody deleted the Disadvantages section [[2]], and I think that content should be reinstated in a more neutral way. CLCStudent (talk) 18:40, 24 August 2018 (UTC)