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

Question

In those days, I repeatedly implemented properties and listeners similar to what JavaFX provides.

Since I always prefer to use widely supported packages rather than what I came up with myself, I really want to use the JavaFX properties in my next project, but before that I would like to get the answer to the next question.

In software that has nothing to do with the GUI, but for change listeners, to monitor and control the state of the system, should I choose the property mechanisms provided by JavaFX, or is there something else available that will work for me? .. Or do I still need to implement this mechanism myself?

Regards, Fredrick

Answer 1

JavaFX property mechanisms should work. They were written to support JavaFX GUIs, but should work just fine for non-gui logic, although I don't think it has been widely used for this purpose so far. I cannot speak with other competitive frameworks that can better meet your needs.

---

When you see the number of classes to support properties in JavaFX, it can be a little more complicated, but they tend to fit together well and there are many classes to not match object mismatches / primitive impedances. It is a pity that there is no better language support for such functions. Programming with the IDE and autocomplete works quite well, so you don't need to type as much. Listeners are dumped into jdk8 lambda expressions, so they can be quite brief.

Binding and listening structures are part of what makes it easy to configure and use JavaFX controls — they intercept change notifications for each element of the system.

JavaDoc is available . Unfortunately, the official documentation for bindings and collections do not do library justice in the detailed description of how to use its feature set. There is a useful article about using JavaFX properties with POJO .

The source for beans, binding, and property support for JavaFX is not yet open (although it is planned to be released in the next few months).

---

Use the Java version later than jdk7u6, and make sure the jfxrt.jar file from the distribution is in your class path, so you select the JavaFX classes. If you are not using any GUI components, you do not need to extend the JavaFX Application class in your program.

---

Relevant non-GUI packages are:

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

javafx.beans.binding Characteristics

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

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

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

javafx.animation Provides a set of classes to simplify the use of transition-based animations (related to timekeeping).

javafx.collections Contains the main collections and utilities of the JavaFX collection

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

Answer 2

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

It is not recommended to mix properties related to the user interface and properties related to business logic.

It works great if both species should not interact with each other. But problems arise when you start associating user interface elements with business logic properties. The reason is that you will often have logic code with a bus in specialized threads, and if this thread updates a property that is part of the binding, you will get the following exception:

java.lang.IllegalStateException: not for FX application thread;

An easy fix is ​​moving a block of code that changes the value of a property to

Platform.runLater (...)

call ... But then you have javaFX-framework dependent code in your business logic code. Therefore, if you reuse this code in a Swing application or just want to test it with the JUnit test, you will also get errors:

java.lang.IllegalStateException: Toolkit not initialized

Since you are using Platform.runLater (), which requires initialization of the JavaFX toolkit, this is not the case with unit test or swing / javaee.

To complete the job, you can use the javafx properties for code other than the UI, but it may have non-trivial side effects ...