Basic Question about Java Bean

Also, is it true that creating a JavaBean is done primarily with the intention of using it graphically (e.g. in an IDE)? My understanding is that EJBs are used throughout the J2EE architecture, but that a class with attributes, accessor and mutator methods technically constitute a JavaBean. However, it appears that some level of serialization is required to be present as well.

Please correct me, if I am mistaken. Recruiters are wanting to know why I don't have "JavaBeans" on my resume when I try to explain it to them. Uugghh.

TIA.

Jeff

marendoj at 2007-6-29 11:17:55 >

Definition

To define a JavaBean is a pretty difficult task. It is easy enough to draw lines between JavaBeans and EJBs, as the first are primarily used in client-side applications and the latter are exclusively used on the server.

"JavaBean" is just Sun's old term for a java class or a java object. I think that at some point in history, James Gosling or some another Java-architect got the idea that a great deal of all future java classes should be designed as beans. The general idea here is: a really superbly designed class is more than just a class. It can go out into the world and do a lot of good. It can call home and bring you money. It can fall in love and be eaten by others which turns them into beans as well.

No, lets get serious.

The idea of "beaning" everything stems from the naive mid-ninetees idea that components are more useful than programs and that expensive programmers will be replaced by wallpapers of beans in the future. What an idea!

There are two surviving packages of bean-stuff in the JSDK. Look at them if you like.

The most important one:

<i>java.beans</i>

contains some interfaces such as

BeanInfo

that forces you to add documentation support to your class.

The primary ideas introduced in these two packages are:

1. Properties. (Bound and constrained)

2. BeanInfo.

3. Hierarchies of executable beans.

4. The ability to make a movable graphical component that can be used to build applications visually in IDE's

The other package

<i>java.beans.beancontext</i>

"Provides classes and interfaces relating to bean context. A bean context is a container for beans and defines the execution environment for the beans it contains." (Taken from the class description in the API.)

Hope this was of some help.

Morten Hjerl-Hansen

Kepler222 at 2007-6-29 11:17:55 >

Basiclly yes. Your bean is just a simple class.

Like one of the former post says, a java bean is just a spesialized class. In your case it is not so spesialized because you have a constructor with an argument.

One part of the definition of a bean is that the constructor has no argument.

There is no need to have a bean if a regular class does the work.

TheLaw at 2007-6-29 11:17:55 >

Here is the difference that I see from my experience with Java Beans:

You can write a Java class or a Java Bean to do similar things. For example, you can write an object that generates an event (example: generate a point x,y), you can write a listener or set of listeners (example: a graph to plot the x,y) to listen to this event and to respond to the event.

The difference is, when you write a simple java class, you hard code the list of listeners, i.e., in the code of the event generator you create an object of the listener within the generator and then notify those objects when an event is generated. If you create another listener object, you will have to modify the event generator code by adding this new listener in the code and recompile it.

With a bean, you create an object that generates an event (with an event object as the argument). In the code of the generator you don't have to specify which objects will be listening to the event. Then you can have several listener objects that listen to this event, obtain the event object and use the values in the event object to make any modifications in itself (for example a graph listener can plot the x,y obtained from the event object). Here is where you have the main difference, you can now dynamically connect the generator to one or several listeners (the events and listener methods are exposed through the descriptors). You can create a new listener and connect the generator to the new listener. You don't have to hard code the listeners into the generator. (I think that somehow in the background when you connect the event of the generator to the listener, a code is generated similar to the java classes that I mentioned above).

hsenapat at 2007-6-29 11:17:55 >