JavaBeans

A Java technology intended to provide a simple component-oriented development model for Java. Official site: http://java.sun.com/products/javabeans/

In a nutshell, a JavaBeans component (bean for short):

• encapsulates some useful functionality into an object, implemented as a Java class
• has some properties, specified with getters and setters: the foo property of type String would be implemented by methods public String getFoo() and public void setFoo(String)
• has a public no-argument constructor so a new bean can be made by a tool
• is serializable using JavaSerialization^? or J2SE 1.4's JavaBeanArchiving^?
• may have methods which must be public to do additional actions
• can fire changes using event sets and the JavaEventModel^?
• may have BeanInfo^? giving its MetaData more precisely than can be found through JavaReflection^?

A common use of JavaBeans is to create visual components, usually based on Swing. Many JavaIDEs support creating visual forms by assembling beans. You can make a beanified form into an applet or application.

Many people now use non-visual beans, for example in server applications. J2EE supports beans in JSP pages, for example.

API's and libraries

• java.beans
• java.beans.beancontext
• Apache Commons BeanUtils - Utilities for manipulating beans
• http://dozer.sourceforge.net/
• http://ezmorph.sourceforge.net/
• http://beanlib.sourceforge.net/

Discussion about JavaBeans

Are JavaBeans suitable as a model for the typical ValueObject (VO)?

I would assert that the answer is "no". Here's why.

(Here, "Value Object" refers to a data-centric class which typically maps rougly to a database record.)

JavaBeans have had a lot of market success. So much so, that newcomers can get the impression that "everything is a bean", and thus, that JavaBeans form the de facto standard for modeling problem domain objects. (For example, the remark above "J2EE supports beans in JSP pages" is indeed correct. However, any object can be used in a JSP, not just objects which implement the JavaBeans style.)

But as mentioned above, JavaBeans were invented for very specific purposes - that of manipulating graphical components in an IDE. Here is the case for not using JavaBeans as a model for typical VOs:

Serializable.
VOs are not usually Serializable. See Effective Java for why Serializable should not be implemented lightly.

No-argument constructor + multiple setXXX methods.
JavaBeans are typically constructed in a piecemeal fashion, using a no-argument constructor, and then by calling various setXXX methods. As a general model for object construction, this is very unusual.

Reasons to not follow this style of construction include

• it is more complex than a single call to an "all-arguments" constructor, since one call is replaced by many
• there is no simple way to ensure that all needed setXXX methods are called
• it allows the object to be in intermediate states which are often not useful
• it is not clear when the ClassInvariant, if any, is established
• it is not compatible with the (very useful) ImmutableObject pattern

As a final point, note that in the Design Patterns book, there is a recurring theme of using constructors as the sole means of passing around needed information; the abstract methods have clean signatures since implementation-specific data is passed to constructors, not to abstract methods.

Some might even argue that, for typical Value Objects, JavaBeans form an anti-pattern, and should usually be avoided as being an inappropriate model for such objects.

What do you think?

-- JohnOHanley - 19 Jul 2003

I think this is a strange question; since the definition of a JavaBean^? matches the definition of a ValueObject very closely. Both contain nothing but data. I feel the real question thus is not whether a persistent object should be a JavaBean^? object, but how you create such a JavaBean^? object. And a side question is wheather using data-only objects is usefull at all.

The side question first; is it usefull to have a data-only object? The answer is a usual one; "It depends". In the case of persistent data, my answer would be no, it is not usefull at all. It creates a lot of overhead or it duplicates locality of data. Reading your story above, I feel we agree on this.

The question of constructing a ValueObject is more a question of how the values are fetched from the persistent layer, and your story above seems to assume a factory will fetch the data and fill it in some way using those setter methods. But then we already agree that that is not really a nice way of doing things.

I propose that a ValueObject has 2 constructors, one which creates an empty (never before stored) persistent object, and one that has a unique identifier in its constructor to let it fetch itself from the persistence layer. So before the constructor ended all the data has been 'set' in the object. If you look at the API, that extra constructor (and maybe something like 'store()') is the only thing which makes it different from the JavaBean^?. How this object will be implemented internally is something I leave as an exercise to the reader, I'll just say that I did it using a wrapper object.

-- ThomasZander - 20 Jul 2003

I thought a ValueObject was one that had its equals method and hashCode method based on the value of its fields, not its memory address!

Here is a compiler that enforces the value pattern: A Pattern Enforcing Compiler (PEC(TM)), it also enforces other patterns.

-- Main.hlovatt - 20 Jul 2004