While you could implement an Observable interface as outlined by Campbell Ritchie, you don't need to do that (at least if I understood what he was writing which perhaps i didn't ;-). That's like implementing things from first principles, which is useful in really understanding concepts but not really necessary here. StringProperty already exists in JavaFX and it already implements an
Observable interface. So the JavaFX developers have already done all of the work of implementing all of the patterns that Campbell Ritchie outlines.
In fact, the original code your wrote in your question is the recommended way of establishing bindings of string based data.
If using
rather than
causes you dislike due to the verbosity, then you might like to look into something like
ScalaFX or the Kotlin based
TornadoFX, which use some tricks unique to their language base to allow you to use the assignment operator rather than a set method to invoke a JavaFX property setter. However, as you seem to just be getting started with JavaFX, I would advise sticking with Java until you are more comfortable with JavaFX development in Java before attempting JavaFX development in another language.
> Java kinda started out with this whole concept of being able to bind objects to other objects ... as somewhat of a Java special skill
Actually it didn't. Java as a language does not have binding within it (you won't find it mentioned in the Java language specification). The binding logic has been added via later JRE implementations as API libraries. The binding and property implementation in JavaFX only became a part of the Oracle JRE distribution a few years ago and is still not shipped with many non-Oracle JRE distributions. No Java Specification Request has been filed to make the JavaFX property implementation a part of the JRE for non-Oracle java vendors, though, as I understand it, there is an intent to file a specification request at some date in the future. Nevertheless, as long as you are using Oracle JRE or an OpenJDK implementation which includes a JavaFX build, then the JavaFX property implementations will work.
> Anybody know whether that Observable interface and the change listener are generally applicable, or whether they are specific to JavaFX
I assume you refer to
javafx.beans.Observableand not
java.util.Observable.
The JavaFX Observable and ChangeListener interfaces are currently specific to JavaFX (see above). However, as long as the JavaFX libraries are present in the JRE that you are using as your runtime, then you can use the JavaFX binding and property systems from any Java program (i.e. they don't require the JavaFX system to be initialized or that your application inherit javafx.application.Application). The
prototypical tutorial for Java bindings from Oracle does not use JavaFX applications at all while using properties and bindings.
I recall one of the JavaFX the developers who created the binding and property system as well as the transition, animation and timeline systems, mentioned that the design was to have those systems implemented and useable outside of the JavaFX GUI libraries. I think they managed to achieve that for bindings and properties but not for transition, animation and timeline (which I think may have ended up tied to some hardware clock and native screen refresh rate detection code). So, perhaps in Java 9 or 10 it will be possible to use a modular JDK which includes modules for JavaFX properties and bindings, but not the whole JavaFX GUI toolkit.
If interested in potential applications of JavaFX properties outside of a JavaFX client app, see:
http://www.marshall.edu/genomicjava/2014/05/09/one-bean-to-bind-them-all/
-----
Aside: If you have model classes that implement standard plain java beans getters and setters but do not fire changes because they don't implement PropertyChangeListener (very common situation), you can make use of a javafx.beans.property.adapter.JavaBeanStringProperty which "provides an adapter between a regular Java Bean property of type String and a JavaFX StringProperty". I have not seen much use of the adapter classes in code and they are not well documented.