25 Java Beans

Pravin Jain

epgp books

 

Introduction

 

This module is here to have some knowledge about Java Beans. When we develop any web application we will be following an architecture we call it as MVC. When we use MVC we will be coming across Java Beans components. Let us try to understand what is java beans components. We will be looking at the java beans in slightly more detail but not too much of detail. Java Beans are very simple just define a plain component which has a property. Let us see what do you mean by java beans it is not just properties.

 

Why JavaBeans came what is the history.

 

All the programming languages always come with some kind of development tools, there are IDEs also even for java we got lot of IDEs and the various options like NetBeans, Eclipse etc.. Similarly we have other programming languages like Visual basic, its a basic language but we have GUI tool for it. Basically the idea here is there are tools which are helpful for development but what this tools are doing for us, These tools have their own libraries of component which are helpful in using, if we use NetBeans, Eclipse. I want to create some GUI application, so development some component the tool will develop it will have its own library of components. If we were using any windows application developing a windows based application on window as platform, we used to have something called ActiveX component, what was that ActivateX component? A component which can be used on windows platform across various languages. Same way here what is java beans, it is here a component, a simple component technology which is used by various tools here for the java platform. it is a java component technology for the java platform.

 

There are lots of standards which has been defined for how it would be used by tool for example in most of the cases the tool like NetBeans IDE or any other java based IDE could be using the java based component. Java Beans is nothing but a Component based technology. The way it is used in web application, it is simple plain component which has got the few properties. It is a component used for storage of some information and it would have some get and set methods which we call as properties. So from web application point of view Java Beans can be a very simple thing. But, if we talk about it in general then Java Beans is a much more than just get and set methods.

 

It is more about how it is used there, is much about related to how it is used inside a tool, a tool like NetBeans or Eclipse etc.

 

A Java Bean component from development point of view it is going to be some kind of a public class. A few requirements for Java Beans, it must always be public class. A public class recommended should be Serializable so that it can easily be transported across. These Java Bean components would have the set of properties. He would have in particular class definition some instance variable which would store information and for that instance methods they provide getter setter methods. These getter setter methods form properties.

 

So if someone wants to have properties he would have get and set methods. If i talk about GUI components which is used in AWT, we have a componets like a Button. What does the button have? Button has the property called label beacuse it has a pair of method. It has a method called getLabel and a method called setLabel and therefore label becomes the property for the Button.

 

All components are inheriting certain properties from the Component class. These components have the property of visible and its type is boolean true or false. visible is a property for all components any class which extends from the Component class. The visible is a property because we have a pair of method again, a method to fetch the value and the method to set the value. We have a method called setVisible which has a boolean value and we have a method called isVisible because it is a boolena type and in this case the convention here is to use is and not get other than boolean the convention is to use get and set methods.

 

So if we develop a public class and if we put a number of get and set methods, the various pair of get and set methods where a get method returns a particular type value and the corresponding set method takes the value of the corresponding type and return type is void this has to be public. If we have such pair of methods that creates one property for us. This is the default behavior for Java Beans. In any Java Beans, it is simple to have properties by just introducing the pair of methods. What is the purpose of this method, a method which can fetch the value and the method which can set the value and the class should be public. Who recognize this properties and where is this properties are going to be used. It is used in any IDE. In an IDE you do drag and drop, you drag and drop your component from the component library. When you drag the component and drop it into the frame you come across the property list. How is this property list created in the tool? This is where the Java Beans technology comes into the picture.

 

How does it identifies that these are the properties for so and so component? For that purpose it uses this Java Beans standards. If you want to have properties we will have the pair of methods. Now i am developing a public class and inheriting from some other class and from that class I am inheriting some of the public get and set methods but are all those get and set methods are going to be properties for me? If i am inheriting they will all become properties. Do we have a mechanism of controlling what should be considered property over here? Should NetBeans consider every get and set property for me? or may be i have some other method? I have not get the method called get and set but i have got the method called read and write may be. Read so and so or write so and so. It is just a question of fetching the value and setting the value for my property. So is it just get and set that will decide? If we follow conventions the things can be simple. When i inherit there is not everything should become property for me. I am developing a component and I don’t want every get and set to be a property or I have got a pair of method which can get me a value which can allow you to change the value but that should still be a property. The Convention here is a get set. There is a proper mechanism for specifying what should become the property and what should not become the property.

 

BeanInfo

 

So for that whenever we develop a component a component is accompanied by a BeanInfo, so may if you are creating your own class, let us say you are creating a new Button, it is a button but it is a new kind of button. If I create a class called NewButton and this is going to be a java bean related class, I decided it to be java bean component, in that case if i want full control over it, then i must develop another class which will give information about the properties of the NewNutton, so if I am creating NewButton class I must also create a class called NewButtonBeanInfo. So every bean class can have a bean info. Whatever the name of the bean class I will put the suffix of the BeanInfo. This BeanInfo is not just any class, it is a class which must implement the interface called BeanInfo. we have this interface called BeanInfo in the java.beans package.

 

The purpose of this BeanInfo is something like, if it finds that there is a BeanInfo then it is going to use the methods on the BeanInfo, invoke the methods of BeanInfo to fetch the methods of the beans. Whenever we have the component and we add the component to the library tool, we will be shown the palette of all the components. So, on the palette there will be always some kind of an icon to represent your component. What can be the icon? that information again comes from the BeanInfo. If you have BeanInfo, you have control over what should be the icon in component. So we have a interface BeanInfo and it has a number of methods there, and if you want to have some help it should have default implementation of all the methods there in a class called SimpleBeanInfo. So whenever we develop a BeanInfo, we normally use the SimpleBeanInfo class as a base class and extends from their and write our properties.

 

Property Descriptor

 

Can I control the list of properties? For our bean we will also have the accompanying BeanInfo class and the implementation of the BeanInfo should override the method called getPropertyDescriptors(). Yes there is the class called PropertyDescriptor. So, we have PropertyDescriptor to return getPropertyDescriptor in the bean info which will be returning the array of PropertyDescriptor.. So this PropertyDescriptor we have the name of the property, what we want as the name of the property. What is the method to get the property? What is the property to set the value of the property which is the getter method? which is the setter method? All such things can then be specified, so we have the proper BeanInfo and its not necessary that we have the get and set convention to be followed always whenever we want to have property for our component. If there is a get set method should it become a property for the component. no it is just a method. In BeanInfo we have a method called getPropertyDescriptors returnung an array of PropertyDescriptor.

 

public PropertyDescriptor[] getPropertyDescriptors()

 

One element of PropertyDescriptor per property. So the number of elements return in this array is the number of properties which will be recognized by the tool. So this is how it is decided how the tool should recognize your component.. So we have getPropertyDescriptor().

 

Like the component has the property, the component also has the set of methods which will be exposed. A component would have the set of events so we have similarly just like we had getPropertyDescriptors() to return array of PropertyDescriptor, in the BeanInfo we also have the getMethodDescriptors() to return what are the method which should be recognized by the tool.

 

public MethodDescriptor[] getMethodDescriptors()

 

Not all methods have to be recognized, same way what are going to be the events which are to be recognized by the tool. So getEventSetDescriptors we have EvenSetDescriptor.

 

public EventSetDescriptor[] getEventSetDescriptors()

 

So there are the classes like PropertyDescriptor, EventSetDescriptor, MethodDescriptor in the java.beans package. These are something which should be return from the implementation of the Bean Info. So you might be extending from the SimpleBeanInfo and overriding these kind of methods. So now what you want as an icon.

 

public Image getIcon(int iconKind)

 

For that also we have method called getIcon on our BeanInfo interface. So it should return Image, so whatever Image is returned that becomes our icon for our bean. This getIcon() method requires a parameter. There are four values for these parameter – the monotype like 16×16 or 32×32, colour 16×16 or 32×32 so there are those four options.

 

public static final int ICON_MONO_16x16

public static final int ICON_MONO_32x32

public static final int ICON_COLOR_16x16

public static final int ICON_COLOR_32x32

 

So you can create four different icons make them available and have implementation of the getIcon() to return appropriate Image for the icon which can then be used by the tools.

 

Like properties we have also got the EventSets and you can define what kind of events. If you have new event to be added for event set we will have a pair of methods. If you have event there you can always develop listeners corresponding to the event. Therefore you will have listeners and event two things which the developer would have created and as far as the component is concerned, it must have addxxxListener and removexxxListener that is the pair of method our bean component must provide.

 

Simple properties

 

In jave beans we have got various kind of properties, what we have seen earlier may be we follow the getter setter method. There is getter method with return type and no parameters and there is a setter method which takes the same type of parameter as the return type of getter method and return type is void for the setter method. If there is a pair of method like this then it becomes the property.

 

Indexed properties

 

We have other types of property, we have various type of properties here. Another type of property is the indexed one. Indexed type of property is the one where the return type in the getter method is an array for the getter method without parameter will return an array and then the setter method would definitely be taking an array. But not only these two methods, if it would be an indexed property then it would add another pair of method, another getter and setter method with the same name but this will have the parameter. The getter method would have the parameter for the index position so that individually ordering of the index position within the array. Also you could fetch the value from the index position within the array so providing getter method for index position within the array and the setter method to set up the value at any particular index position within the array. So it has four methods and not just two methods. If there will be the indexed property. The indexed properties are the properties which are of array type where there is a provision of accessing individual index position of the array.

 

Bound properties

 

Another thing which may be useful, in many places we have properties which are said to be bound properties – It is a Simple property where there is a provision to register if some developer uses that component can then to register a listener to listen to the changes in the property. Whenever the property value changes I have a listener which can indicate there is a value which has been changed.. Some kind of code which executes dealing change in this kind of properties. So a provision is made in the component itself. So the compnent in this case is just not having the get and set methods.

 

PropertyChangeListener

 

Another pair of method which would be needed here is addPropertyChangeListener(), removePropertyChangeListener() where you would have as parameter which registers a change in listener for bound properties.

 

public void addPropertyChangeListener(PropertyChangeListener listener)

public void removePropertyChangeListener(PropertyChangeListener listener)

 

So, components have provision for registering listeners for bound properties. So when a developer is using this component, he is not using this component but he is able to listen which can listen to change in the property of components.

 

In the bound properties there are a few things which has to be done in the setter method of the bound properties. It is the setter method which is going to be invoked when there is a change. So a value change is done through a setter methods. So in the setter methods there is a parameter which is to be received,.on receiving the parameter the code would be to set the method and wherever it stores the value there will ba an instance variable to store the value. It is not about changing that but you have updated the value. Now also see that if we have someone who is registered for listening to this property or change in this property he is intimated about it and for that there are other useful classes which are available to us.

 

Property Change Support

 

We have PropertyChangeSupport class which can be used by our component. The component’s responsibility is to intimate the registered listeners. One thing in provision is allowing someone to register to listen for the changes in the property. He is now also having responsibility whenever the bound property value changes to intimate the listeners. To help to manage the listeners and to be able to intimate about the property change to the registered listeners we have the class called PropertyChangeSupport. PropertyChangeSupport has all types of methods. It has also got the methods called addPropertyChangeListener, removePropertyChangeListener etc.

 

So what you need to do is just use this class in your jave bean component class, you can have one instance variable for property change. Whenever somebody says addPropertyChangeListener on your component simply invoke the same method, just pass it on to the PropertyChangeSupport object which you have. If you have done such a thing then whenever the property changes you simply have to call the method on propertyChangeSupport object saying that so and so value has changed. It is then the responsibility of the PropertyChangeSupport, the object of it will then intimate the listener about this change. So we have this class for simplifying the management of PropertyChangeListeners for the bound properties, and helping us to inform the registered listeners whenever the property changes. For that we have to invoke the method of PropertyChangeSupport in our setter method. So we have the method called propertyValueChanged which has to be invoked on the PropertyChangeSupport, and we need to specify what was the old value, what the new value and what is the property name?

 

Constrained properties

 

Another thing we have here is Contraint property. In this we allow the listeners to be registered which can veto the property change. What we mean here is if someone tries to change the property can it be changed to any value?? No it should be controlled.

 

So here the developer creates the component which we call as a VetoableChangeListener. It can be registered with some kind of java bean component which has got something called constrained property. Is there is constrained then it will be using the component similar to PropertyChangeSupport component, there is a VetoableChangeSupport component which can be used here also And the setter methods in such a case is not going to change the value first but before doing that it has to invoke the method of VetoableChangeSupport component letting it know that this is the change it has been proposed.

 

If none of the VetoableChangeListener is throwing an exception then it is ok to proceed with the change and then you make the change and intimate the boundPropertyListeners. So if there is a property which has both constrained as well as bound it would have provision for methods addPropertyChangeListener() and removePropertyChangeListeners(). Similarly for constrained property we have addVetoableChangeListener() removeVetoableChangeListener(). When a developer writes VetoableChangeListener what he does is, he wil do the check whether this change is allowed or not The method in the VetoableChangeListener is the one where it gets the PropertyChangeEvent. The same object is also available in the PropertyChangeListener. There parameter is PropertyChangeEvent. Same parameter is also found in the vetoableChange method of VetoableChangeListener. Here object of PropertyChangeEvent has the old value, the new value and the name of the property. So here the VetoableChangeListener examines the old value , the new value and then will decide the change is allowed or not. If the change is not allowed then it will simply throw an VetoException. There is an exception class called PropertyRedoException which redoable change methodw normally use.

you can view video on Java Beans

Suggested Reading:

  1. JavaBeans Programming from the ground up, by Joseph O Neil and Herb Schildt, McGraw Hill.
  2. Developing Java Beans, by Robert Englander, O’Rielly
  3. https://docs.oracle.com/javase/tutorial/javabeans