Hmmm. I thought the beans were used primarly to produce gui components via a visual editor. The link says that "There is nothing about the JavaBeans framework that implies that Beans should be graphical objects" but still graphical objects seems to be its primary use. Maybe I am incorrect, though.
> Hmmm. I thought the beans were used primarly to
> produce gui components via a visual editor. The link
> says that "There is nothing about the JavaBeans
> framework that implies that Beans should be graphical
> objects" but still graphical objects seems to be its
> primary use. Maybe I am incorrect, though.
That's because at the time, the main use of beans the designers foresaw was creating reusable widgets and the like to be plugged into the pallettes of IDEs. Things didn't quite work out that way though, much like the complete failure of applets to set the web on fire
That link also says:
The JavaBeans API includes several interfaces and classes in the java.beans package. In addition, it employs interfaces and classes from other Java technology API areas including:
* The Java event model: java.util.EventObject, java.awt.event
* Object serialization: java.io.Serializable, java.io.Object*
* Reflection: java.lang.reflect
I use events and serialization often. Does this means I have java beans experience?
> That link also says:
> The JavaBeans API includes several interfaces and
> classes in the java.beans package. In addition, it
> employs interfaces and classes from other Java
> technology API areas including:
>
> * The Java event model: java.util.EventObject,
> java.awt.event
> * Object serialization: java.io.Serializable,
> java.io.Object*
>* Reflection: java.lang.reflect
> use events and serialization often. Does this means
> I have java beans experience?
No. In fact, it makes no mention of your competencies whatsoever
According to wikipedia (not the ultimate source i realize) A JavaBean is a POJO that is serializable, has a no-argument constructor, and allows access to properties using getter and setter methods. By that definition, i do have java beans experience.
You've addressed (and somewhat answered) the question in the back of my mind: What's the big deal with "beans"?
The JavaBeans framework provides a "standard" api for bean components. That's the big deal. It doesn't sound like much until you grasp the idea that by implementing the standard certain things can be assumed true and that opens up possibilities for things like builders, and portability and such.
It's not a silver bullet it's a way of approaching things. I've found it interesting over the years that at different times the development community has maintained that accessors and mutators are bad and should never be used, or this or that other thing or some other fancy that comes down the pike and is the "Next big thing".
Just my 2 krupplenicks on the subject, your milage may of course vary.
PS.