In JavaFX, the Properties API allows developers to bind values to UI controls. This capability is surprisingly easy, but when object models use properties too often, an application can quickly run out of memory.

In the world of JavaFX, the Properties API allows UI developers to bind values to UI controls. This capability is surprisingly easy; however, when object models use properties too often, an application can quickly run out of memory. I usually will write two separate objects such as a POJO class and a presentation model object. This technique is often used in Swing-based applications. From a JavaFX perspective, you could just create one object with properties to allow observers (listeners) to update values. This sounds fine, right? Not exactly, because the main issue is when all of the object’s (POJO) attributes (fields) are properties that also wrap actual values, the programmer (user of the API) may not want to bind or use properties at all, but only want to access the actual values. So, what is a JavaFX developer to do?

I often go to the blog Pixel Perfect by Dirk Lemmermann, who will often post very useful JavaFX tips. Recently, Dirk blogged about how to save memory using an interesting pattern called Shadow Fields. To see his post, please visit his blog entry JavaFX Tip 23: Save Memory! Shadow Fields for Properties. Dirk’s JavaFX tip does help solve the problem mentioned above (lessening the heap); however, I noticed boilerplate code that has to exist to provide (a smart determination) to the caller of whether the return is the actual object or the property wrapper object. For example, instead of returning an IntegerProperty object when calling get or set methods, the code will return an int or Integer value, thus saving memory. Furthermore, the code declares two variables to hold one of the two value types. For example:

I felt I could make things more concise and possibly save more memory while reducing the boilerplate code. I decided to create an interface with Java 8’s default methods that will handle managing actual values and properties. The user of the API will simply create a domain class that implements the following interface:

Interface PropertyAccessors

This is an interface providing accessor methods to provide a smart determination of the actual object value or the JavaFX property wrapper object. The user of the API must implement one method called getModelProperties(), which returns a Map of the property name (String) and its value (Object). The value can be an actual object or a Property type object. The code below also will support Observable lists.

Employee Class

This is a class named Employee, which implements the PropertyAccessor interface. Below you will notice the property name of each field is declared using a public static final String. For example, the employee’s name is:

public static final String NAME_PROPERTY = “name”;

For the accessor methods such as getters, setters, and xyzProperty(), you will notice the calls to the default methods in the PropertyAccessor interface.

Conclusion

So there you have it: a solution in an attempt to eliminate two variables and other boilerplate code. I haven’t actually tested the code with a large amount of data, so maybe in another post I (or some lucky reader) will create a test comparing all three implementations (the object with all properties, Dirk's, and mine).

The possible downside to this approach is probably serializing the object when used with RMI servers. I’m sure there are other possible downsides, but for now, for most use cases, this might be easier and cleaner code to deal with.