 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2007Java Bean Question
Hi gang, Are all Java Beans the same? What I'm getting at is that I have seen some examples on the internet that show sample Java Beans created without them implementing the Serializable interface. So if I use a Simple Java Bean with implementing the Serializable interface, invoking it from withing a JSP via "use:bean...", is it still a valid / legal Java Bean? Thanks again, Chris > Hi gang, > [quoted text clipped - 7 lines] > Serializable interface, invoking it from withing a JSP > via "use:bean..." [sic], is it still a valid / legal Java Bean? Yes. The question of being a JavaBean is not a question of being Serializable. Primarily to be a JavaBean means to follow the convention that there is a getX() and setX() for all properties X, except booleans which have an isX() and setX() method. There are also notifications and events connected to beans, but that doesn't affect the ability to use <jsp:useBean> or <c:set> or Expression Language (EL) references. You do need to make an object Serializable to safely make it a session object. Making a class Serializable incurs a huge responsibility. Serialization is another public interface to a class, and it exposes the implementation (private members). Joshua Bloch covers the issues in his seminal book /Effective Java/. Just follow the accessor (getX() or isX()) and mutator (setX()) method conventions for all attributes and your class will work with JSPs just fine for scope less than session.  SignatureLew > > Hi gang, > [quoted text clipped - 9 lines] > > Yes. The question of being a JavaBean is not a question of being Serializable. That was my main concern, because I have seen some examples with and without implementing it. > Primarily to be a JavaBean means to follow the convention that there is a > getX() and setX() for all properties X, except booleans which have an isX() [quoted text clipped - 5 lines] > > You do need to make an object Serializable to safely make it a session object. Ah, I see, thanks. > Making a class Serializable incurs a huge responsibility. Serialization is > another public interface to a class, and it exposes the implementation [quoted text clipped - 4 lines] > conventions for all attributes and your class will work with JSPs just fine > for scope less than session. Ok, I will do :-) Thank you again for your help. Chris > Primarily to be a JavaBean means to follow the convention that there is > a getX() and setX() for all properties X, except booleans which have an > isX() and setX() method. [snip] > Just follow the accessor (getX() or isX()) and mutator (setX()) method > conventions for all attributes and your class will work with JSPs just > fine for scope less than session. <soapbox relevancy="not for OP"> This is one of the most pervasive misconceptions about any part of Java. JavaBeans aren't just about convention! The spec actually allows you to override the names of the getter/setters that go a property. There is also the concept of different "views" of the bean. For a beginner, its fine just to use the "conventional" approach to JavaBeans, but its amazing how many "professional" tool sets implement their own bean accessing through the Reflection API and get the spec WAY wrong. </soapbox> Sorry, just a pet peeve of mine. JavaBeans are far more than POJO, but many people seem to dismiss that. Ohwell :-) Daniel. SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> >> Primarily to be a JavaBean means to follow the convention that there >> is a getX() and setX() for all properties X, except booleans which [quoted text clipped - 16 lines] > Sorry, just a pet peeve of mine. JavaBeans are far more than POJO, but > many people seem to dismiss that. Ohwell :-) You raise very important points, albeit beyond the scope of what the OP needs. Sometimes it's better to take a simplified explanation, as I did, rather than try to lay out all the complexities of the JavaBeans specification. Obviously you see this, given your remarks "for a beginner". For the so-called "professional" tool sets a higher standard does apply. I commend you for calling attention to the more advanced issues. For those that needed the full story, I did provide the link to the specification, repeated here so others will not make the sort of mistake you described: <http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7224-jav abeans-1.01-fr-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg> SignatureLew It will work, but according to the JavaBean specification JavaBeans should implement the Serializable interface. So it's simply good practice to do so. And if you are in a clustered envirnment you need it anyway, so from the point of view of a scalable architecture it is recimmende too. By the way: Does your Javabean have an explicit default constructor ;-) > Hi gang, > [quoted text clipped - 11 lines] > > Chris > It will work, but according to the JavaBean [sic] specification JavaBeans should Please do not top-post. > implement the Serializable interface. So it's simply good practice to do so. Unnecessary for JSPs unless the bean scope is session or larger, and incorrect in any case. It's not required that JavaBeans implement java.io.Serializable, which the specification explicitly states right at the start: >> A bean is not required to inherit from any particular base class or interface. <http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7224-jav abeans-1.01-fr-spec-oth-JSpec&SiteId=JSC&TransactionId=noreg> Section 2.1, "What is a Bean?" > And if you are in a clustered envirnment you need it anyway, so from the > point of view of a scalable architecture it is recimmende [sic] too. Again, only if used at session scope or larger. It's actually much better not to make the Bean Serializable unless you absolutely have to. There is a lot of work to make a class implement java.io.Serializable correctly. Don't do it unnecessarily. > By the way: Does your Javabean [sic] have an explicit default constructor ;-) It only needs to be explicit if there is a non-default constructor or if it does significant construction work, not usual for JSP beans. Why the smiley? Summary: JavaBeans do not need to be Serializable, and should not be unless necessary. Only make the default constructor explicit if necessary. SignatureLew On Oct 8, 6:21 pm, "Franz-Josef Herpers" <Franz- Josef.Herp...@ger.sas.com> wrote: > It will work, but according to the JavaBean specification JavaBeans should > implement the Serializable interface. So it's simply good practice to do so. > And if you are in a clustered envirnment you need it anyway, so from the > point of view of a scalable architecture it is recimmende too. Thanks, but according to the link posted by Lew, it seems it is not always required. > By the way: Does your Javabean have an explicit default constructor ;-) Yes indeed :-) Cheers, Chris > On Oct 8, 6:21 pm, "Franz-Josef Herpers" <Franz- > Josef.Herp...@ger.sas.com> wrote: [quoted text clipped - 5 lines] > Thanks, but according to the link posted by Lew, it seems it is not > always required. Discouraged, really. >> By the way: Does your Javabean have an explicit default constructor ;-) > > Yes indeed :-) Why? SignatureLew > > On Oct 8, 6:21 pm, "Franz-Josef Herpers" <Franz- > > Josef.Herp...@ger.sas.com> wrote: [quoted text clipped - 7 lines] > > Discouraged, really. Ok, I see. > >> By the way: Does your Javabean have an explicit default constructor ;-) > > > Yes indeed :-) > > Why? Because I had read somewhere that it was required for a JavaBean, just as I read that Serializable was. -- Chris "Franz-Josef Herpers" wrote: >>>> By the way: Does your Javabean have an explicit default constructor ;-) >>> Yes indeed :-) Lew wrote: >> Why? > Because I had read somewhere that it was required for a JavaBean, just > as I read that Serializable was. That is every bit as much a myth as the other false belief. There is absolutely no mention in the specification of a pattern for the constructor, not even that there must be a default constructor, much less that it be specific. In fact, a Bean is not even limited to a single class. The spec recommends instantiation through a call to Beans.instantiate(). Most Bean frameworks do seem to require that there be a default constructor for Bean classes, but none that I know of require it to be explicit. Summary: Serializable is not a required interface for a Bean, and a Bean need not have an explicit default constructor. SignatureLew > "Franz-Josef Herpers" wrote: > >>>> By the way: Does your Javabean have an explicit default constructor ;-) [quoted text clipped - 6 lines] > > That is every bit as much a myth as the other false belief. Point taken, but that's what I have read. Just to clarify, does that myth also apply to enterprise java beans? > There is absolutely no mention in the specification of a pattern for the > constructor, not even that there must be a default constructor, much less that > it be specific. In fact, aBeanis not even limited to a single class. Again, it's just what I have read in some tutorials, possibly even on Sun's own site. > The spec recommends instantiation through a call to Beans.instantiate(). Just out of interest, where would you make that call? (servlet, JSP, etc...) > MostBeanframeworks do seem to require that there be a default constructor > forBeanclasses, but none that I know of require it to be explicit. > > Summary: Serializable is not a required interface for aBean, and aBeanneed > not have an explicit default constructor. But if I supply my own user defined (overloaded) constructor that takes arguments, doesn't the side effect of that cause the compiler or JVM to *not* provide a default constructor anymore? thus it has to be explicitly defined? or is it still not a requirement that it be present at all? Thanks, Chris > Point taken, but that's what I have read. Just to clarify, does > that myth also apply to enterprise java beans? Enterprise JavaBeans are a completely different animal. Lew wrote: >> There is absolutely no mention in the specification of a pattern for the >> constructor, not even that there must be a default constructor, much less that >> it be specific. In fact, aBeanis not even limited to a single class. > > Again, it's just what I have read in some tutorials, possibly > even on Sun's own site. Citations? I take my information from the JavaBeans specification document, which one might take to be authoritative. Did you read it? >> The spec recommends instantiation through a call to Beans.instantiate(). > Just out of interest, where would you make that call? (servlet, JSP, > etc...) Anywhere you instantiate a Bean. I admit I've never followed that recommendation, but then I haven't been using the full power of the JavaBeans framework. > But if I supply my own user defined (overloaded) constructor that > takes arguments, doesn't the side effect of that cause the compiler > or JVM to *not* provide a default constructor anymore? thus it has > to be explicitly defined? or is it still not a requirement that it > be present at all? Did you notice upthread that I said: >> It only needs to be explicit if there is a non-default constructor >> or if it does significant construction work, not usual for JSP beans. ? This is the usual rule for default constructors. SignatureLew > > Point taken, but that's what I have read. Just to clarify, does > > that myth also apply to enterprise java beans? > > Enterprise JavaBeans are a completely different animal. Ok. > Lew wrote: > >> There is absolutely no mention in the specification of a pattern for the [quoted text clipped - 6 lines] > Citations? I take my information from the JavaBeans specification document, > which one might take to be authoritative. Did you read it? Well, I did say *possibly* from there, but it could be that I was reading about EJB's, like you mention above. Actually, I just had a quick look on their tutorials, and even though these are *not enterprise tutorials*, I found the following: ======== BEGIN ======== JavaBeans Design Issues JavaBeans objects are like other user-defined data types, but with the following additional options that make the objects more useful: Providing a public no-argument constructor Implementing java.io.Serializable Following JavaBeans design patterns Set/get methods for properties Add/remove methods for events Java event model (as introduced by JDK 1.1) Being thread safe/security conscious Can run in an applet, application, servlet, ... For an IDE to instantiate a bean, the class implementation must provide a no-argument constructor. [...] Nongraphical Beans [...] >From the previous sections, it's clear that "Bean-ifying" a class can be quite simple because of the default Bean functionality. Minimally, you must provide a no-argument constructor, implement the Serializable interface, and so on as described previously. ======== END ======== Now I presume that the statement "described previously" is refering to "JavaBeans Design Issues" above. I see in other pages however where code examples do not include an explicit default constructor. I hope that you can see why I have been confused over these issues. [snip] > Did you notice upthread that I said:>> It only needs to be explicit if there is a non-default constructor > >> or if it does significant construction work, not usual for JSP beans. Yes, sorry about that, I did miss it. > This is the usual rule for default constructors. Thanks, Chris > Actually, I just had a quick look on their tutorials, and even though > these are *not enterprise tutorials*, I found the following: [quoted text clipped - 4 lines] > JavaBeans objects are like other user-defined data > types, but with the following additional options Key word: "options". > that make the objects more useful: > > Providing a public no-argument constructor Nothing here about it being explicit. > Implementing java.io.Serializable This directly contradicts the specification document. > Following JavaBeans design patterns > Set/get methods for properties [quoted text clipped - 5 lines] > For an IDE to instantiate a bean, the class > implementation must provide a no-argument constructor. Nothing about being explicit. > I hope that you can see why I have been confused over > these issues. It is difficult sometimes, when information is fragmented over multiple sources like this. Here is one place where they say, "Beans must provide a no-argument constructor", and over there another place where they tell you that you can do so implicitly, but don't mention Beans. This business of integrating information from wildly disparate sources is among the strongest learning skills a developer can have. I am always feeling overwhelmed by the abundance of information I have to assimilate to do work in this field, and not just in the Java universe. SignatureLew > > Actually, I just had a quick look on their tutorials, and even though > > these are *not enterprise tutorials*, I found the following: [quoted text clipped - 6 lines] > > Key word: "options". Yes. > > that make the objects more useful: > > > Providing a public no-argument constructor > > Nothing here about it being explicit. Yes, again I agree, but their example code does show an explicit one, and in seems that NetBeans automatically adds it there for you. > > Implementingjava.io.Serializable > > This directly contradicts the specification document. Ok. > > Following JavaBeans design patterns > > Set/get methods for properties [quoted text clipped - 7 lines] > > Nothing about being explicit. Well, that statement is not that cut and dry, to be honest. The way it is worded *seems* to suggest otherwise. It might have been better understood had it used the term: *default constructor* By reading that statement, and having an understanding that initialising objects during instantiation is a good object orientated practice to employ via various constructor overloads, it seemed reasonable to think that you will always need to explicitly provide the default constructor. > > I hope that you can see why I have been confused over > > these issues. [quoted text clipped - 3 lines] > no-argument constructor", and over there another place where they tell you > that you can do so implicitly, but don't mention Beans. Yes indeed, and that is truly my problem at the moment. There is so much information on Java, so many acronyms, so many deprecated features with so many versions of java, thus different ways of approaching a problem, that it is difficult to get a grasp of what is core and what is add-on, etc... Even books discuss old java..."this is how it was done in version XYZ,...etc" mixed with new which doesn't help, and the many tutorials on the web are either out of date or don't go into enough detail. > This business of > integrating information from wildly disparate sources is among the strongest > learning skills a developer can have. > I am always feeling overwhelmed by the abundance of information I have to > assimilate to do work in this field, and not just in the Java universe. I can understand that :-) Thanks again, Chris > Yes, again I agree, but their example code does show an > explicit one, and in seems that NetBeans automatically > adds it there for you. I'm not certain that all versions of NetBeans have all templates set up to do that. In any event, if you don't want NetBeans to insert an explicit constructor, remove it from the template. >> Nothing about being explicit. > [quoted text clipped - 4 lines] > > *default constructor* "Default constructor" means the no-arg constructor in Java. They are exact synonyms. If you understand it with one term, then you understand it with both, otherwise you don't understand it. "Seems" how? Provide evidence. Java has a rule that there is a default constructor provided under certain circumstances; following an instruction to provide such a constructor means that you might choose to let it happen automagically. That is a choice you make given understanding of the language. > By reading that statement, and having an understanding > that initialising objects during instantiation is a > good object orientated practice to employ via various > constructor overloads, it seemed reasonable to think > that you will always need to explicitly provide the > default constructor. Unless you know that you can provide it implicitly, which is a very basic rule of Java. >>> I hope that you can see why I have been confused over >>> these issues. Sure, but don't hang on to the confusion. You've had a clarification, now let go of your personal history and move on. > There is so much information on Java, so many acronyms, > so many deprecated features with so many versions of > java, thus different ways of approaching a problem, that > it is difficult to get a grasp of what is core and what > is add-on, etc... That's why they pay us the big bucks. If it was easy, everyone would do it. SignatureLew > "Default constructor" means the no-arg constructor in Java. They are > exact synonyms. If you understand it with one term, then you understand > it with both, otherwise you don't understand it. Oops. You were right and I was wrong. "Default constructor" does indeed mean the *implicit* no-arg constructor with no "throws" clause. <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8.9> SignatureLew > > Yes, again I agree, but their example code does show an > > explicit one, and in seems that NetBeans automatically > > adds it there for you. > > I'm not certain that all versions of NetBeans have all templates set up to do > that. I am not certain of all versions either, it was just an observation. More importantly, I presented it to show you that there was some influence from Sun (especially for newcomers), using the power of suggestion. > In any event, if you don't want NetBeans to insert an explicit constructor, > remove it from the template. Yes, of course :-) [snip - I read your latter post] > > By reading that statement, and having an understanding > > that initialising objects during instantiation is a [quoted text clipped - 5 lines] > Unless you know that you can provide it implicitly, which is a very basic rule > of Java. Yes, I know that. The rule is exactly the same fror C++. Its a matter of style and wording in the tutorials that is confusing :-) > >>> I hope that you can see why I have been confused over > >>> these issues. > > Sure, but don't hang on to the confusion. You've had a clarification, now let > go of your personal history and move on. I take your point very well, and that is exactly what I am trying to do, but it will take a little time to adjust, thats all. > > There is so much information on Java, so many acronyms, > > so many deprecated features with so many versions of [quoted text clipped - 3 lines] > > That's why they pay us the big bucks. If it was easy, everyone would do it. Hehe, yeah! Thanks, Chris On Sun, 07 Oct 2007 23:46:09 -0700, "Chris ( Val )" <chrisval@gmail.com> wrote, quoted or indirectly quoted someone who said : >So if I use a Simple Java Bean with implementing the >Serializable interface, invoking it from withing a JSP >via "use:bean...", is it still a valid / legal Java Bean JavaBeans have their own different serialisation mechanism. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Oct 10, 9:41 pm, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > On Sun, 07 Oct 2007 23:46:09 -0700, "Chris ( Val )" > <chris...@gmail.com> wrote, quoted or indirectly quoted someone who [quoted text clipped - 5 lines] > > JavaBeans have their own different serialisation mechanism. By "their own different serialisation mechanism", do you mean that you implement a different interface to Serializable? Thanks, Chris On Thu, 11 Oct 2007 05:34:54 -0700, "Chris ( Val )" <chrisval@gmail.com> wrote, quoted or indirectly quoted someone who said : >By "their own different serialisation mechanism", do you mean >that you implement a different interface to Serializable? no, I mean the PersistenceDelegate mechanism. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Oct 12, 6:35 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote: > On Thu, 11 Oct 2007 05:34:54 -0700, "Chris ( Val )" > <chris...@gmail.com> wrote, quoted or indirectly quoted someone who [quoted text clipped - 4 lines] > > no, I mean the PersistenceDelegate mechanism. Ok, thanks for the information. -- Chris Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.