Should I use something else in non-gui applicaiton logic than the mechanisms that javafx.beans.property provides?

Question

Back in the days, I have more than once implemented properties and listeners similar to what is provided by JavaFX.

As I always prefer to use widely supported packages rather than something I have invented myself, I feel very tempted to use JavaFX properties in my next project, but before that, I would like to get an answer to the following question.

In software that has nothing to do with GUI, but would benefit from change listeners in order to monitor and control system state, should I still choose the property mechanisms provided by JavaFX, or is there somethin else available that would work for me? ...or am I still in need to implement this mechanism by myself?

Regards, Fredrik

Answer 1

JavaFX property mechanisms should work. They were written to support JavaFX GUIs but should work fine for non-gui logic as well - although I don't think there has been widespread usage for that purpose thus far. I can't speak to other competitive frameworks as to which may address your needs better.

---

When you see the number of classes for property support in JavaFX, it can be a bit daunting, but they tend to hang together quite well and a lot of the classes exist to shield object/primitive impedence mismatches. It is a shame there is not better language support for such features. Programming with an IDE and autocomplete works quite well so that you don't need to type as much. The listeners fold into jdk8 lambda expressions so they can end up quite concise.

The binding and listener frameworks are part of what allows JavaFX controls to be so readily adapted and utilized - they provide hooks into change notifications for every item of the system.

JavaDoc is available. Unfortunately the official documentation on bindings and collections does not do the library justice in thoroughly describing how to use it's feature set. There is a useful article on using the JavaFX properties with POJOs.

The source for beans, binding and property support for JavaFX is not yet public (though it is scheduled to be made public over the next few months).

---

Use a version of Java later than jdk7u6 and ensure the jfxrt.jar file from the distribution is on your classpath so that you pick up the JavaFX classes. If you are not using any GUI components, you don't need to extend the JavaFX Application class in your program.

---

Relevant non-GUI packages to consider are:

javafx.beans The package javafx.beans contains the interfaces that define the most generic form of observability.

javafx.beans.binding Characteristics of Bindings

javafx.beans.property The package javafx.beans.property defines read-only properties and writable properties, plus a number of implementations.

javafx.beans.property.adapter (adapts standard pojo beans to JavaFX properties).

javafx.beans.value The package javafx.beans.value contains the two fundamental interfaces ObservableValue and WritableValue and all of its sub-interfaces.

javafx.animation Provides the set of classes for ease of use transition based animations (timing related non-gui portions).

javafx.collections Contains the essential JavaFX collections and collection utilities

javafx.util.converter This package is for standard string converters for JavaFX.

Answer 2

After using javaFX properties for non UI-related logic for about a year on a commercial product, here is my two cents:

It may not be a good idea to mix UI-related properties and Business-logic-related properties.

It works great if both kind does not have to interact with each other. But problems arise when you start binding UI elements to Business-logic properties. The reason is you will often have busness-logic code running in dedicated threads, and if this thread updates a property that is part of a binding, you will get the following exception:

java.lang.IllegalStateException: Not on FX application thread;

The easy fix then is to move the code block that changes the property value in a

Platform.runLater(...)

call... But then you have some javaFX-framework dependant code in Business-logic code. So if you re-use this code in an Swing application or simply if you want to test it with a JUnit test, you will get errors there too:

java.lang.IllegalStateException: Toolkit not initialized

As you are using Platform.runLater() that requires the JavaFX toolkit to be initialized, at this is not the case in a unit test or a swing/javaee application.

To wrap up, it is possible to use javafx properties for non UI code but it could have non trivial side effects...