What is the advantage of using Java Beans?

Question

I believe I understand what Java Beans are: Java class(es) which contain a no-arg constructor, are serializable, and expose their fields with getters and setters.

1. Does a Java Bean have to expose all of its fields in order to qualify as a bean? If no, does it even have to expose any?

2. May Java Beans include constructors with arguments as well as a no-arg constructor?

3. What is the purpose of Java Beans, other than to conform to a certain coding style? It seems there is a lot of talk about 'beans this' or 'beans that', but I don't know why they are advantageous, specifically.

   I can totally get making the no-arg constructor. There can be a slew of reasons for it, and I wouldn't be surprised if a no-arg constructor helps the compiler do some optimizations, either. I can also understand making your class serializable. Even if the class is never serialized, it could be, and going back to do it retroactively could be annoying (or impossible in a black-boxed library).

   But most curious is the requirement to have fields all accessible via getters and setters. I do use them in my own work when I have need of them, but it seems odd that Java Beans requires them (possibly all of them, depending on my answer to #1). If it's an issue with reflection, couldn't the reflection get the fields just as easily? If it's an issue with doing more than simply setting the value, couldn't the reflection use a getter/setter over a field if the method exists?

Answer 1

Most of all, a Java Bean is a reusable software component.

This means that it is not tightly coupled to other components. If your Java class creates an instance of another class, or returns some specific implementation class, it is no longer a bean. Beans cover some well-defined piece of functionality and are loosely coupled to other classes.

The advantage of this is that you get all these little pieces that you can then get to work together pretty easily. Also, these are easy to reuse and unittest.

Even if you are not using some visual environment to couple beans (as the bean spec suggests), this is still a reason to use beans: to get small pieces of code which are easily usable.

If you don't use a visual tool, it is not that important that your bean has a 0-argument constructor, or is serializable.

Answer 2

They adhere to a clear specification.

Thanks to this there are insanely a lot of tools to ease working with Javabeans (or just the other way round). There are tools which can autogenerate them based on some data in a certain flavor (XML, JSON, CSV, DDL, etc) and/or vice versa, as well to read/manipulate/map them like Commons BeanUtils, Dozer, EZMorph, etcetera. Further there are a lot of MVC/ORM frameworks which works with Javabeans, like JPA, Hibernate, JSF, Spring, etc. Even a bit decent IDE like Eclipse knows how to autogenerate Javabeans based on just some fields.

It are the tools and frameworks around Javabeans which makes our life easier. It is the Javabeans specification which made those things exist.

Answer 3

The biggest advantage is that your beans are built according to a specification and can be used directly with "bean-compatible" libraries and frameworks.

For example, most frameworks for Serialization (XML, JSON, YAML, ...) often can use beans directly without configuration.

Answer 4

A JavaBean on its own is not terribly interesting, it's just a Java class that conforms to some standards that you listed above. However, conformance with this standard is one of the pillars on which the Java EE framework is built and it comes up in quite a few places. I suspect that when you hear about all of the great things that JavaBeans can do, what's being referred to in Enterprise JavaBeans (EJBs). FYI, there are a few different types of EJB listed below:

1. Entity Beans
2. Stateful Session Beans
3. Stateless Session Beans

Some details now follow...

Entity Beans

You might want to read/write objects to/from an underlying database. You could use JDBC/SQL to do this but you could also use a persistance framework. The Java EE spec includes a spec for persistance whereby you declare your class to be an "entity bean" and have Java automatically generate database tables and logic to map between entries in your database and objects in your program. Originally, persistance was something that required the use of an Application Server (such as Glassfish, JBoss, Geronimo etc.) but AFAIK, you can do use it in desktop apps with no server component. The actual implementation is provided by a lower level library such as Eclipselink, Toplink, Hibernate etc. but the Java API abstracts away any differences between them.

Stateful Session Beans

Imagine that you want to create an instance of a Java class which exists on separate JVM. The JVMs might be running on the same physical machine but equally, may be on separate machines communicating over a network. Using a Java EE application server, you can create a class which can be instantiated by clients of the app server. These clients can instantiate a class which will act just like a normal object but any methods that are invoked on the object get executed on the server with the results being passed back to the caller. It's basically an object oriented form of remote procedure calls.

Stateless Session Beans

This is a minor variation on stateful session beans. With stateful beans, if the server has 1000 clients then it will potentially have to create 1000 instances of the bean and remember which instance belongs to which client. With stateless beans, the server creates a pool of beans and doesn't bother to remember which client owns which bean. When a client invokes a method, the server picks a bean from the pool and uses it, returning it to the pool on completion. You use stateful session beans when you want the server to remember details about each client, you will use stateless beans when you don't need to remember client specific details. Note that the stateless beans may well have state, it's just that this state won't be of interest to the client.