Content deleted Content added
m Signing comment by 128.146.248.165 - "" |
Gnomingstuff (talk | contribs) rv 2007 test edit |
||
| (31 intermediate revisions by 23 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=Stub|
{{WikiProject Java|importance=mid}}
}}
== 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. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/128.146.248.165|128.146.248.165]] ([[User talk:128.146.248.165|talk]]) 15:37, 19 February 2009 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:: What the hell kind of layman looks up an article like this and doesn't at least know what a constructor is? [[Special:Contributions/72.227.165.191|72.227.165.191]] ([[User talk:72.227.165.191|talk]]) 04:09, 13 January 2010 (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. [[Special:Contributions/24.23.254.32|24.23.254.32]] ([[User talk:24.23.254.32|talk]]) 03:31, 12 November 2011 (UTC)
::The article fails to say what a Bean ''is'', which is the main thing an encyclopedia article should do. I am familiar with objects and even with constructors, but listing properties is not the same as defining. If an abstract definition becomes too complicated, it may be helpful to give a (basic) example to the use of beans. [[User:Rbakels|Rbakels]] ([[User talk:Rbakels|talk]]) 08:19, 18 May 2019 (UTC)
== 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. --[[User:Sithy|Guillaume]] ([[User talk:Sithy|talk]]) 12:32, 18 January 2008 (UTC)
I agree [[Special:Contributions/24.23.254.32|24.23.254.32]] ([[User talk:24.23.254.32|talk]]) 03:17, 12 November 2011 (UTC)
==Broken link==
Line 17 ⟶ 25:
== Move?? ==
JavaBeans be moved to JavaBeans ??? Is there something I am missing? --[[User:Soumyasch|<
*'''Support''' move. -- [[User:Solipsist|Solipsist]] 12:47, 24 January 2006 (UTC)
Line 30 ⟶ 38:
*'''Support'''. Other page titles are in singular, too. It's one JavaBean, two JavaBeans. [[User:Wlievens|Wouter Lievens]] 14:37, 6 June 2006 (UTC)
I've removed my vote. --[[User:Bonafidehan|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. [[User:RFST|RFST]] ([[User talk:RFST|talk]]) 18:31, 22 January 2012 (UTC)
== Elaboration ==
Line 43 ⟶ 53:
::"[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. --[[User:Sithy|Guillaume]] ([[User talk:Sithy|talk]]) 13:43, 18 January 2008 (UTC)
::: "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. [[User:Amenel|Amenel]] ([[User talk:Amenel|talk]]) 13:12, 15 July 2010 (UTC)
::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. [[User:Dabeamer42|dabeamer42]] 14 July 2008 <small>—Preceding [[Wikipedia:Signatures|comment]] was added at 21:12, 14 July 2008 (UTC)</small><!--Template:Undated--> <!--Autosigned by SineBot-->
::: A JavaBean is a POJO. But the converse is not true. [[User:Amenel|Amenel]] ([[User talk:Amenel|talk]]) 13:12, 15 July 2010 (UTC)
:: 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. [[User:Amenel|Amenel]] ([[User talk:Amenel|talk]]) 13:23, 15 July 2010 (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?) [[User:Lunalot|Lunalot]] ([[User talk:Lunalot|talk]]) 17:10, 28 July 2011 (UTC)
== Naming convention ==
To my knowledge boolean properties are capitalized the same way as other types. Compare Sun's JavaBeans spec [[http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf]] and the java.beans.Inspector.decapitalize(String) method. - leo 03 August 2012 <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/80.218.115.95|80.218.115.95]] ([[User talk:80.218.115.95|talk]]) 22:05, 2 August 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
== Serializable classes ==
Line 50 ⟶ 71:
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 <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/203.197.25.11|203.197.25.11]] ([[User talk:203.197.25.11|talk]]) 12:01, 6 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->▼
== 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. --[[User:Hro%C3%B0ulf|Hroðulf]] (or Hrothulf) ([[User talk:Hro%C3%B0ulf|Talk]]) 08:48, 4 October 2007 (UTC) <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Hroðulf|Hroðulf]] ([[User talk:Hroðulf|talk]] • [[Special:Contributions/Hroðulf|contribs]]) {{{2|}}}</small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->
== Picture ==
I like the example, but it would be nice to see a picture of the output. [[Special:Contributions/138.162.8.58|138.162.8.58]] ([[User talk:138.162.8.58|talk]]) 14:01, 20 May 2009 (UTC)
== 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.
--[[User:imjake9|I'm Jake9]] "Da' Pie!" 05:10, 17 November 2009 (UTC)
== The write once run anywhere advantage is too broad ==
"A Bean obtains all of the benefits of Java's "write once, run anywhere" paradigm."
▲
:Yeah! Computer science – a world of boasting slogans, without any coherent terminology. I detest it too! [[User:Rursus|Rursus]] dixit. ([[User talk:Rursus|<span style="color: red; background: #FFFF80"><sup>m</sup><u>bork<sup>3</sup></u></span>]]!) 09:15, 21 November 2012 (UTC)
== History? ==
When were JavaBeans invented? Have there been any major modifications to the concept since then? [[User:RenniePet|RenniePet]] ([[User talk:RenniePet|talk]]) 02:25, 23 July 2013 (UTC)
== Incorrect ==
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.
[[User:Randallbsmith|Randallbsmith]] ([[User talk:Randallbsmith|talk]]) 19:02, 10 March 2016 (UTC)
== Advantages/Disadvantages sections ==
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 [[https://en.wikipedia.org/w/index.php?diff=856370013&oldid=850841617&title=JavaBeans|here]], and I think that content should be reinstated in a more neutral way. [[User:CLCStudent|CLCStudent]] ([[User talk:CLCStudent|talk]]) 18:40, 24 August 2018 (UTC)
| |||