Advanced-Bindings for JavaFX

I’m a big fan of JavaFX’s Properties and Data-Bindings. In my opinion, one of the most interesting part of the data binding capabilities of JavaFX is that you can create a binding that represents a calculation of values. For example you can create a binding that represents the addition of two integer properties:

import javafx.beans.binding.Bindings;
import static eu.lestard.assertj.javafx.api.Assertions.assertThat;

public void test(){
    IntegerProperty a = new SimpleIntegerProperty(12);
    IntegerProperty b = new SimpleIntegerProperty(30);

    NumberBinding c = Bindings.add(a, b);




There are binding method for basic operations like add, subtract, multiply, divide. But what if you need some more specific operations like exponentiation or sine?

To fill this gap I have created a library called “advanced-bindings” that will become a collection of custom bindings that are needed to create application logic with data bindings. The first step was to create binding implementations for all methods of java.lang.Math. This way you can do stuff like this:

public void testPow(){

    DoubleProperty a = new SimpleDoubleProperty(3);
    DoubleProperty b = new SimpleDoubleProperty(2);

    final DoubleBinding pow = MathBindings.pow(a, b);

    // 3^2 = 9


    // 5^3 = 125

In the future I will add more useful helpers and custom bindings. If you have ideas feel free to add an issue at github.

I have uploaded the library to [maven-central]( eu.lestard advanced-bindings 0.1.0 jar) so you can use it with Gradle:
compile 'eu.lestard:advanced-bindings:0.1.0'

or with Maven:



Again, I have rewritten one of my old games with JavaFX. This time I’ve created a JavaFX version of my old java swing game ColorPuzzle (yes I know, the name isn’t very creative).

screenshot of the game

The game mechanics are the same: You can switch the color of all fields under your control. Everytime you are switching the active color, all fields in the direct neighbourhood of your own fields with that same color are going under your control from now on. The goal is to bring all fields under your control with the fewest moves.

Before you ask: Yes, the game idea is not my invention, there are many games of this type out there and my version is only a clone. I create games only because programming is fun and not to become the best game inventor :-)

The code is available on github:

Grid Component

While the development of the game I have encapsulated the logic for manipulating and drawing the grid and extracted it into it’s own component. This way I was able to reuse the grid logic for other projects like SnakeFX.

You can view the code for this grid component on github too ( but it’s not intended for wide usage at the moment as documentation and testing far from production ready. It’s more like a playground for me.

In another post I will describe the idea behind the grid component in more detail.


Another reason to build the game was to create a simple example for our own UI framework MvvmFX.



As you probably already know I’m a big fan of the AssertJ library. That’s the reason I’ve done a talk about it at the JavaUserGroup Görlitz.

I like the way you can write readable unit tests and are supported by the IDE because AssertJ is implemented as a Fluent-API.

In the past weeks I’ve written a package of assertions specially for JavaFX. With this assertions you can verify the values of JavaFX Properties and Bindings.

With the normal AssertJ you would write something like this:

DoubleProperty x = new SimpleDoubleProperty(10.13);


With my extensions you don’t need to call the .get() all the time. Instead you can write:


Project Info

The project is hosted on github:

I’ve already uploaded it to maven central so you can use it with gradle:

testCompile 'eu.lestard:assertj-javafx:0.1.0'

or maven:


Tell me what you think. If you have ideas for new assertions that could be added feel free to add an issue in the issue tracker.


MvvmFX article in JavaMagazin

In the JavaMagazin 06/2014 there is an article about MvvmFX written by Alex and me.

In this article we describe the design pattern Model-View-ViewModel and show how you can apply it to your application with our framework MvvmFX.

Additionally we were showing some of the internals of JavaFX and MvvmFX. For example I’m describing how the loading of FXML files is done in JavaFX and how we hook up into this process to enable the usage of Dependency Injection frameworks.

Another part of the article is the combination of MvvmFX and SynchronizeFX and how we are using it in our own applications at Saxonia Systems.


JUG-GR: Better readable unit tests with AssertJ

Last week I gave a talk about better readable unit tests with AssertJ at the Java User Group Görlitz.

I talked about the benifit of readable unit tests and what frameworks there are for java developers to archive good unit tests.

One of the main elements of unit tests are assertions. In JUnit we have the static methods assertEquals, assertNotNull and so on. But these aren’t making a good job when it comes to easy readable code. A better readable way is to use the assertThat method that comes with Hamcrest and is also part of the latest JUnit versions.

The problem with Hamcrest is that it is created out of many static methods which has several drawbacks. The biggest one is the bad IDE support.

In the talk I showed the framework AssertJ which is an alternative to hamcrest. It also uses a static assertThat method as the entry point to an assertion but the rest of the API is implemented as a fluent-API. This way the IDE is able to give suggestions of possible assertion methods based on the type that was given as argument to the assertThat method. Look at the following example:

    String message = "hello world, manuel";

With this example the IDE knows that ‘message’ is of type String and it can only suggest assertions that are making sense for strings like startsWith or endsWith. For a parameter of type integer the IDE would instead suggest assertions like isPositive or isBetween(int start, int end).

I realy love this style of writing unit tests. In the talk I gave some other interesting examples of what AssertJ can do for you.



Writing games is a good way of learning a new programming language or framework. I’ve done this several times in the past: JavaScript/Snake , C++/Space-Shooter, Java2D/ColorGame.

This time I was interested in JavaFX 2 and again I was developing a little game as an example. Again I tried a “snake” like game as you probably know from old mobile phones. As the player you are controling a Snake that eats food that is laying around. Everytime you eat something to gather points and grow a little bit. The goal is to gather as many food as you can without byting yourself in the tail. In my version of the game there are no walls: When you move outside of the field on the left side you are immediatelly returning on the right side.


The development started in october 2012 with some experiments with JavaFX, FXML and dependency injection. The first version of the game was based on maven and javaFX version 2. In november 2012 the first version of the game was ready. It was based on maven and JavaFX in version 2. The dependency injection was implemented by hand without a DI framework.

After a long pause with no coding in may 2013 I returned to the project and started with a big refactoring. The code wasn’t realy nice and the coupling between the components of the game was relatively tight. The idea of the refactoring was to encapsulate the state of the UI in a ViewModel. Another change was the usage of JSON for persisting highscores instead of CSV. This way I was able to remove a lot of code for CSV parsing.

In november 2013 again I made some changes to the game after another pause. The biggest change is the use of Gradle as build system instead of maven. I also done a big refactoring of the dependency injection system and simplified the code of the program. Another big simplification was the usage of Java 8 instead of Java 7.

The code of the game can be found on github:



For the lecture “IT security management” at the university my fellow students and me have developed a programm called “Datenpannen-Kalkulator”. “Datenpanne” is the german word for “data loss” and means that you have lost some of your or your companies data.

The programm calculates the costs of losing data or virus infections in your company based on some parameters like the number of affected clients or your industrial sector. The calculation is based on existing statistics in which companies were asked about the costs that were caused by security incidents.


While it’s obvious that the frontend of the application was developed with JavaFX (and the help of Afterburner.fx) the calculation logic is done with JavaFX too. All calculations were implemented with JavaFX’s properties and databinding capabilities. At first this programming style is a little bit unusual because typically as a java delevoper you are used to implement calculations in an imperative style.

But this style of programming has lots of advantages: It’s relativelly easy to implement a “reactive” user interface. The calculation logic is based on properties that are bound to the values of the input fields and the charts that are visualizing the result are bound to the result properties. This means that a change in the input fields immediately leads to a change of the calculated result values and this leads to an update of the displayed chart data. There is no need for a “calculate” or “update” button. It’s all done automatically.

The code of this project can be found on github:



Today I like to introduce another open source library that my workmate Alexander Casall an me are creating at Saxonia Systems. Alex had the idea to try out the design pattern “Model-View-ViewModel” that was created by Microsoft engineers for Windows Presentation Foundation (WPF) and XAML and that is also used by some JavaScript frameworks like KnockoutJS.

The design pattern uses some technical capabilities of a modern UI technolgy like (bi-directional) data-binding and descriptive UI declaration to simplify the development of the UI and to make testing UI code easier.

JavaFX in version 2 supports both of these capabilities: It includes Properties and Data-Bindings and FXML, a xml dialect to create the UI for JavaFX.

At the moment our MvvmFX-library is at the very beginnning. We are trying out what is possible and what is not. We would be very pleased if you like to give it a try. You can find it on github:

The MVVM Design Pattern

Let’s start with the View. With MVVM the view has to be silly. It may not contain any logic but only describe what is visible in the UI.

The UI specific logic is developed only in the ViewModel. The viewmodel contains the whole state of the UI and the logic that updates and changes this state. It provides the state to the outside in the form of Properties.

The view can now bind itself to the properties of the ViewModel. When the state of the viewmodel changes the view is automatically updated because of the binding.

The viewmodel knows the model. How exactly the model is created isn’t part of the MVVM pattern. It is the interface to the business logic and the rest of the application. The viewmodel takes the informations that are needed to be presented in the view from the model and brings that informations in the right form in which the view needs them.

A common example is a UI that should show the name of a person. The model has Person instances that are containing string variables for “forname” and “surname”. In the UI you are expecting this informations to be presented in a nice way. The viewmodel would take the person instance and concatenate the for- and surname to one single string that is provided as a property “name”. The view has a label that’s textProperty is bound to the name property of the viewModel.

The design pattern defines a strict top-down visibility for the components. The View knows the ViewModel. The ViewModel knows the Model but not the View. And the Model knows neither the View nor the ViewModel.


What is really cool about this design pattern is that the whole UI specific logic is only located in the viewmodel. Conditions like “Is the button x disabled or enabled?” are developed in the viewmodel. The view doesn’t know about this conditions. It only knows that there is a button and that it’s visibility property is bound to a boolean property in the viewmodel. The view doesn’t care about under which conditions this boolean property is true or false.

This enables you to unit-test your UI logic. The viewmodel is only a simple Java class. You don’t need to boot-up the whole application to perform difficult UI integration tests. JUnit is all you need.


SynchronizeFX article in JavaMagazin

I’m very pleased that an article of my colleagues and me with the title “SynchronizeFX: Remote JavaFX Property Binding” is released in the JavaMagazin 08/2013.


In this article we describe the use cases that induced us to create the SynchonizeFX library and how we are using it in our own product eteoBoard. Additionally some of the implementation details are described and of cause a little how-to is part of the article too.