When to make a class a bean?

Question

I can understand that if you have a GUI type class where you might want to make the class a Bean so that it can be used in tools like BeanBox.
But what if it is a non visible class? For example say a class that is used to interface to piece of equipment over the serial port? Are there any advantages to making the class a Bean?

Answer 1

Ok. My info may be a little out of date, but I'll try.
In object oriented programming, we have these things called patterns. They are called that because that's what they are caled in the original book by the "gang of four", whose names I can't recall. An example of a pattern is the idea of passing an event around, or having graphical objects "inside" other ones, or making a class that serves as an interface to a complex set of other classes. These patterns are not always directly supported by the APIs or language, they are more abstract than that - ways that we programmers go about architecting solutions to certain kinds of problems. (nb: a pattern is not the same thing as an algorithim). Of course, some patterns are supported directly by the APIs: EventObject, EventListener etc.
One common pattern is an object that holds a set of values, that fires events and so on. Of course any object can do this, but architecturally speaking, some objects work that way more naturally than others. In Java, we call such an object a JavaBean.
Java supplies a standard for JavaBeans at http://java.sun.com/products/javabeans/docs/spec.html . This standard specifies that a java bean has a null argument constructor, it has getters and setters and that if a bean has a getFoo() method and a setFoo() method, then these together mean that the bean has a "property" named Foo, and so on.
Now physically, the only thing that a java bean must have is:
it must be public,
it must have a public, no-argument constructor
However, architecturally, we make a load of assumptions. For instance, if your class has a getFoo() and setFoo() method, but they have absolutely nothing to do with each other, then you class isn't a JavaBean, even though physically the compiler and tools have no way to know this. Likewise, if your class has a public no-arg constructor, but your class requires that you call the setup() method for it to work properly, then it is not a JavaBean. JavaBeans can be initialised into a reasonable starting state with the constructor alone.
So JavaBean or not JavaBean is not a class you inherit or an API you use, it's a way of doing things.
Having said that, there is api support for JavaBeans in the java.bean package. You can create "BeanInfo" classes for your beans that contain metadata about the beans: long textual descriptions for the properties, icons for tools to use when displaying the beans and so on.
As for JSPs:
From memory, you can tell your JSP that an instance of a bean is to be created for each session that the JSP deals with. So say we make a bean that acts as a shopping cart, with items that themselves are beans (item number, quantity). Inside the JSP you can do things like "print shopping cart.item[2].name", and the JSP will know to convert this to a call to foobean.getItem(2).getName(). The reason for making it a bean is to make it possible for the web server to manage the creation of these things and the retreiving of them on a session-by-session basis. They can also be passed as arguments and so on. Another nice reason to use a bean is that you can encode derived values as getter methods on the bean (eg: getTotalPrice()). This is a nice place to put such logic.
The JSP spec is at http://www.jcp.org/aboutJava/communityprocess/final/jsr053/ . (dont confuse it with the servlet Spec, which is on the same page). See section 4.1: Standard Actions/usebean.