Dawson College will again be hosting Montreal’s NetBeans Day. Unlike large commercial conferences NetBeans Day is a community organized event. With NetBeans now part of the Apache Foundation the day is about more than just the NetBeans IDE. It is also a celebration of all things open source. The event is free to attend (with refreshments) and targeted at students, professional software developers and anyone with a general curiosity.

In my earlier article, The Bean Class for Java Programming, I presented how I want you, my students, to code a data or model class in your assignments. That style of bean class is widely used in frameworks such as Hibernate, Java Server Faces, CDI and others. There is one variant of that class that you need to know about and that is the JavaFX bean class.

JavaFX is the modern GUI framework that is the successor to Swing as it was the successor to AWT. One important characteristic of JavaFX is that the observable pattern is baked into its beans, pun intended. When a JavaFX bean is bound or connected to a JavaFX control. such as a text field, changes to the control can automatically update the bean and changes to the bean updates the control. This is an important feature in the Model View Controller pattern that JavaFX promotes.

A JavaFX bean, when properly constructed, can be a drop-in replacement for a Java bean in most instances. It is expected to adhere to all the mandatory, optional and even bonus features I described in the earlier article. Let’s begin by reviewing the fields from that article.

I have added an additional field to make this bean a little more interesting. The field will represent the date that the book was published.

private LocalDate datePublished;

To make this bean observable we must change how we declare these fields. JavaFX introduced a family of wrapper classes called property classes. These property classes exist for the primitive types, the String, List, Map, Object, Set and a catch all for any other class type. These classes come in read / write as well as read only versions. They also come in abstract and concrete classes. The abstract class is the property type (LHS) and the concrete class is the instantiation (RHS). Here is a table of the read / write property classes.

The abstract property classes define the required methods of a property in a general way. The concrete class may override the general methods but do not add any additional methods. JavaFX has other concrete property classes that can appear on the right-hand side. The concrete classes extend the abstract class. This is an example of pure inheritance.

The next change that we make from the original bean is that we now must have a constructor. These property fields are null references to abstract classes so you must instantiate them. If you do not plan to have a non-default constructor then all you need is something like this:

The default constructor uses Java’s ability to have a constructor call another constructor by overloading. The non-default constructor can now be used to create an instance of the object and at the same time this class has the required default constructor.

The setters and getters must also be modified. These methods are expected to get or set the value inside the property object and not the property itself. This is easy to do as property classes have a get and set method to handle this. Here are the setters and getters.

With this syntax we now have a drop in replacement for standard Java beans as described in my first article. This is not complete yet. We are using property classes to achieve an observable pattern. To accomplish this JavaFX controls must be bound or connected to the individual fields. The controls need a reference to the property object. Only the equivalent of a getter is required. There is no naming convention because we write out the method name when we do the binding. The most common naming approach is to add the word Property to the variable name. Here are the getters for the properties.

JavaFX does require that you use JavaFX beans as described here. They are only required if you intend to take advantage of binding to controls. If binding is not required then an ordinary Java bean should be used.

To summarize these two articles, if you are not using JavaFX then I expect you to use the Java bean class for data and models in the work you submit to me. In a JavaFX application I expect you to use the JavaFX bean whenever binding is required.