Java Bean Question

[Chris ( Val )]

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

 

[Lew]

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..." [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.

 

[Franz-Josef Herpers]

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 ;-)

 

[Lew]

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:
<http://javashoplm.sun.com/ECom/docs...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.

 

[Chris ( Val )]

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..." [sic], is it still a valid / legal Java Bean?

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()
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.

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
(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.

Ok, I will do

Thank you again for your help.

Chris

 

[Chris ( Val )]

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

 

[Lew]

Thanks, but according to the link posted by Lew, it seems it is not
always required.

Discouraged, really.

Yes indeed

Why?

 

[Daniel Pitts]

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.

 

[Chris ( Val )]

Discouraged, really.

Ok, I see.

Why?

Because I had read somewhere that it was required for a JavaBean, just
as I read that Serializable was.

 

[Lew]

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

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...spec-oth-JSpec&SiteId=JSC&TransactionId=noreg>

 

[Lew]

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.

 

[Chris ( Val )]

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

 

[Lew]

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.

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?

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:?

This is the usual rule for default constructors.

 

[Chris ( Val )]

Enterprise JavaBeans are a completely different animal.
Ok.



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

Yes, sorry about that, I did miss it.

This is the usual rule for default constructors.

Thanks,

Chris

 

[Lew]

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

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
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.

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.

 

[Chris ( Val )]

Key word: "options".
Yes.



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.

This directly contradicts the specification document.
Ok.



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.

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.

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

 

[Roedy Green]

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.

 

[Lew]

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.

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*

"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.

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.

 

[Lew]

"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>

 

[Chris ( Val )]

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