Implement your own Redux in Java. Part 4: Middleware


In this series of blog posts I'm implementing my own Redux in Java to use with JavaFX.

However, the purpose is not to create a production-ready library (because there is already ReduxFX available) but instead to learn by re-implementing it.

In the previous part I've introduced the basic concept of "middlewares", one of the extension mechanisms of Redux. However, in the first approach I was using a simplified API for middlewares to get a better understanding of the concept. The actual API of Middlewares is a little more complex. In this part I will show the limitations of the previous API and what kinds of middlewares you can't build with it. Then I will transform the API and the implementation to the "real" API. This will be a prerequisite to implement middlewares for asynchronous behavior, which will be the topic of the next part.

Topics in this blog series (maybe I will adjust this in the process of writing):


Implement your own Redux in Java. Part 3: First approach on Middlewares


In this series of blog posts I'm implementing my own Redux in Java to use with JavaFX.

However, the purpose is not to create a production-ready library (because there is already ReduxFX available) but instead to learn by re-implementing it.

In the previous part I've showed how to connect the basic redux store to a JavaFX view. In this part I will take a first look into the first extension mechanism that Redux provides: Middlewares.

Topics in this blog series (maybe I will adjust this in the process of writing):


Highlight Days in JavaFX DatePicker


Today I had the requirement to implement a highlighting of some days in the JavaFX DatePicker. As I haven't found an existing blog post or tutorial that describes this topic I will provide a short example here.

Similar to other JavaFX controls like ListView or TreeTable the DatePicker can be configured with a CellFactory. In this cellFactory you can configure the styling of individual cells.

The basic code looks like this:

DatePicker datePicker = new DatePicker();

datePicker.setDayCellFactory(new Callback<DatePicker, DateCell>() {
  public DateCell call(DatePicker param) {
    return new DateCell() {
      public void updateItem(LocalDate item, boolean empty) {
        super.updateItem(item, empty);

JavaFX will reuse existing DateCell instances when the visible viewport is changed when the user switches between pages in the DatePicker. This way JavaFX saves resources and minimizes new instances as much as possible.

To reuse existing cells we need to override the updateItem method which will get the new LocalDate object as parameter. Inside this method we can now check if this day should get a special styling.

In my example I will highlight the holidays (in Saxony, Germany) with a special color.


Implement your own Redux in Java. Part 2: Simple FXML Views


In this series of blog posts I'm implementing my own Redux in Java to use with JavaFX.

However, the purpose is not to create a production-ready library (because there is already ReduxFX available) but instead to learn by re-implementing it.

In the previous part I've showed how the basic Redux functionality can be implemented. In this part I will show how to use it with JavaFX and how to combine a simple FXML based JavaFX View with our Redux store.

Topics in this blog series (maybe I will adjust this in the process of writing):


Implement your own Redux in Java. Part 1: Basic Redux functionality


To learn and understand new tech things I'm often implementing them on my own. I mean, How hard can it be? This time I'd like to show how to implement Redux with Java targeted towards JavaFX. The purpose here is not to actually use this implementation because there is already a really good one available. The purpose is only to see that Redux actually isn't that complex when it comes to a basic implementation of the library. As this topic includes a lot of sub-topics I will start a little series of blog posts that will cover the implementation of a Redux library in Java, the extension mechanisms of Redux and how to use them with JavaFX.

Topics in this blog series (maybe I will adjust this in the process of writing):


GraphQL Example App 'Bloggie'


In the past I've given several talks on GraphQL (JavaLand 2017, JUG Saxony, JUG Berlin, BEDCon 2017, OOP 2018), a query language for web API's. In those talks I've used the example of a blog application with the name "Bloggie". Today I have made the github repository of this example public so that everyone interested in this example app can see the source code.

You can find it here:

bloggie screenshot

The app shows articles and authors both in a overview page and a details page and a comment section will be added in the future. The idea of this repository is to not only contain a single example but instead to implement the same use-case with different technologies and implementation styles.

At the moment I have a backend implemented with node.js and a frontend written with React.js and Apollo Client but in the future I'm planning to add other variants too. For example, a student I'm mentoring has compared several ways to implement GraphQL servers. This includes node.js, pure Java and Java with Java-Persistence API. So it's likely that I will add a Java implementation too.

In the frontend I'm planning to add another implementation with Angular and maybe another react-variant using a different graphql client library.

What is important to notice here is: This app is not intended for real-world usage! It's neither optimized for a good usability as a blogging platform nor can I guarantee the absence of bugs or security issues. The only purpose of the repository is to show and learn technologies and patterns around GraphQL.

One of the reasons to "open-source" the example app is that I'm planing to write more blog posts on GraphQL, React, Redux and other web technologies in the future. Because even though I'm programming with JavaScript for 10 years now and I've also used react.js, redux and GraphQL for several applications I haven't been blogging about these topics in the past.


Javaland 2018: Talk about Immutables


I will be speaking at the Javaland conference 2018. This conference is organized by the iJUG e.V. which is the association of german speaking Java User Groups of which we as JUG Görlitz are a part of. The conference is also special because of the location: It will take place in the Phantasialand Brühl, a theme park in the area of cologne. It will last from 13th to 15th of march.

javaland banner

My talk will be about immutable data with Java. As I'm a fan of functional programming, I'm using immutable data structures a lot. For example when developing applications with Redux both in JavaScript and in Java, immutability is an important thing to keep in mind. For me personally, thinking in immutable objects is not a big deal anymore. It's natural and by this time I'm used to it. But when I talk to other developers or doing code reviews I sometimes see people having problems with this kind of development style. Therefore I hope to give a good introduction to the topic with the talk and also show how people can implement their own immutable data structures in Java - either by hand or by using third-party libraries. And I will also take a short look at other JVM languages like Kotlin or Frege.


JavaFX Dialogs: How to set min-size and prevent closing?


In this post I will write about two problems with JavaFX dialogs and how to solve them: How can you set a minimal size for a dialog and how can you prevent the dialog from closing?

How to set a min-size for JavaFX Dialogs?

If you create a JavaFX Application Window without further configuration, you can resize the window without limitations. This means you can change the size so that no content is visible anymore.

todo app with JavaFX

To prevent this you have to set a minHeight and minWidth on the Stage of the window:

public class TestApp extends Application {
	public void start(Stage primaryStage) {
		VBox root = new Vbox();


		primaryStage.setScene(new Scene(root, 400, 400);;

With Dialog you have a similar situation. By default JavaFX Dialogs are not resizeable but it is possible to change this default behavior. However, if the Dialog is set to be resizeable you are then able to minimize the size to 0 pixel like with the application window. In contrast to the main application window you can't set the min-size on the Dialog though. At least not directly.

To fix this you have to set the min-size on the stage of the dialog. This can be done like this:

Dialog dialog = new Dialog<>();

final Window window = dialog.getDialogPane().getScene().getWindow();
Stage stage = (Stage) window;


How to prevent the closing of a Dialog.

Another situation that we were facing in a real-world app lately was to prevent closing of a JavaFX Dialog when some validation logic has failed.

In the JavaDoc for the Dialog class you can find two paragraphs that look promising at a first glance: "Dialog Validation / Intercepting Button Actions" and "Dialog Closing Rules".

The first one tells you how you can add validation rules for dialog buttons and how to prevent the dialog from closing if the condition is not met when attempting to close the dialog.

With the lookup method of the DialogPane you can get the buttons of the Dialog and add EventFilters on them. If your validation fails you can consume the event to prevent the Dialog from closing:

Dialog dialog = new Dialog();

dialog.getDialogPane().getButtonTypes.addAll(ButtonType.OK, ButtonType.CANCEL);

TextField textField = new TextField();


// Create an event filter that consumes the action if the text is empty
EventHandler<ActionEvent> filter = event -> {
	if(textField.getText().isEmpty()) {

// lookup the buttons
Button okButton = (Button) dialog.getDialogPane().lookup(ButtonType.OK);
Button cancelButton = (Button) dialog.getDialogPane().lookup(ButtonType.CANCEL);

// add the event-filter
okButton.addEventFilter(ActionEvent.ACTION, filter);
cancelButton.addEventFilter(ActionEvent.ACTION, filter);

The code above creates a Dialog with a TextField and two Buttons (OK and CANCEL). You can't close the dialog with these buttons as long as the TextField is empty. In many situations this may not be your desired behavior: Typically you like to prevent closing with the OK Button but allow the user to cancel the action and close the dialog with the CANCEL button. However, in other situations you may want to achive exactly this: Prevent the closing even when the cancel button is pressed. So everything is ok with this code? Not quite. You can still click the "x" in the window of the dialog and the Dialog will close no matter what your validation says.

This is when the second part of the JavaDoc page comes into play. It describes the rules when it's possible to close a Dialog "abnormally" (which includes clicking the "x" but also pressing some OS specific shortcut like Alt+F4 on Windows). These rules are not bad. You can only close a dialog this way if the dialog has a CANCEL Button. From a usability perspective this makes sense: If the user can't finish the process in the dialog she may want cancel it either by pressing the cancel button of the dialog or the "x" in the window title.

But what if (for some reasons) you have other requirements? What if you have to prevent the closing even though it might not result in good usability? For this usage there is no easy API available.

But it is still possible with some workarounds: In JavaFX you can prevent the closing of a Stage by adding an event-filter with the setOnCloseRequest method. With this knowledge you can use the same approach from the beginning of this article to access the Stage of the dialog to add this event-filter:

Stage stage = (Stage) dialog.getDialogPane().getScene().getWindow();

stage.setOnCloseRequest(event -> {
	if(tf.getText().isEmpty()) {

New mvvmFX version 1.6.0 released


This week I've released a new version of mvvmFX. In this blog post I will highlight some of the new features and changes.

EasyDI integration

Support for dependency injection was always one of the main goals of mvvmFX and one of the first features we had implemented. Previously, mvvmFX was supporting CDI/Weld and Guice as dependency injection frameworks. With the new release we added support for the small DI library EasyDI.
I've written EasyDI as a dependency injection alternative for small to medium projects with the goal of an easy setup without extra configuration but with the tradeof of haven limited features compared to full-fladged DI frameworks like CDI or Guice. If you are interested in EasyDI you can read more about it here and here.

Validation in separate module

We have extracted the Validation feature into it's own maven module. This way you can use the validation mechanism without having to import the whole mvvmFX module. If you are using the validation classes and you upgrade to the new version you will have to add the mvvmfx-validation module to your maven/gradle build file. Everything else (i.e. package names) stays the same.

Additionally we have improved the ObservableRuleBasedValidation to be more flexible. Instead of an ObservableValue<Boolean> you can now also use an ObservableValue<ValidationMessage> as rule to control when a validation is failed and which message should be used in this case.

Lifecycle methods for ViewModels

It's now possible to add lifecycle hooks to the ViewModel. This way you can react to the event of the View being added to or removed from the SceneGraph. This can be useful to implement housekeeping of listeners or cleanup of used resources.
However, at the moment we see this as beta: It works for many of our use cases but we aren't 100% sure if there are hidden side effects that we haven't thought of yet. As always we highly appreciate your feedback.
At the moment this lifecylce hook is only available for FXML bases Views and only in the ViewModel. For the next version we are planing to add it for Java code based Views and the CodeBehind classes itself.

This is just a first step to help preventing memory leaks. For the next version we are also planing to provide a way to prevent unintentional garbage collection of Controller/CodeBehind classes as a second step.

New example app showing asynchrounous behavior usind CompletableFuture

There are many ways of handling asynchrounous behavior in JavaFX apps. One that I personally like a lot is using java's CompletableFuture. Therefore I've added a new example app that shows how you can use CompletableFuture with mvvmFX to wrap a blocking/synchrounous backend service in the ViewModel and still have a non-blocking UI. You can find the example code here.

I hope you like the new release. Tell us how you like it and provide feedback in the comments or in the issue tracker of the project.


TodoMVC for JavaFX


In the JavaScript world there are thousands of libraries and frameworks available for you to use for your next application. And with plenty of choice there comes the agony of choice. Before you can even think about choosing the "best" framework you need a set of frameworks that you will take a closer look at in the second step. To get a first impression of a framework and to help you decide which framework is worth a closer look, one starting point is the TodoMVC project. It contains the same simple task management app created with different Web/JavaScript frameworks.

TodoMVC logo

It's not a real-world application and ignores lot's of topics that are important for a typical web application. But it gives you a basic idea of the core principles and approaches of each framework and the differences between the frameworks. Another nice aspect of TodoMVC is that you can see a basic project setup for the framework of your choice. The TodoMVC app is neither too trivial (like the typical "hello world") nor is it too complex to understand the code anytime soon.

The idea to have a small set of requirements that are implemented with different approaches, libraries and frameworks isn't only limited to JavaScript frameworks but would be useful in other domains like JavaFX too.

For this reason I've started a "TodoMVC JavaFX" Project. Let's create the same app with different JavaFX frameworks! You can find the repository of the project on Github:

The first idea to start this kind of project came to me after a talk I gave at the Java User Group Görlitz on "UI Design Patterns". In this talk I was comparing several MVC variants by implementing the same app with each pattern (here you can find the code).

Some time later I was creating a Todo example app for mvvmFX which I later used as starting point for the TodoMVC JavaFX project.

todo app with JavaFX

At the moment there are 3 implementations: First there is a "reference implementation" that only uses pure JavaFX without any framework. It's meant be a reference of how the application should behave and look like. Developers can take FXML, CSS or Java files from it to start with their own implementation.

The second example is the mvvmFX implementation I've mentioned above. The third example uses FluxFX, an experimental library that I've created for a talk on how to implement the Flux architecture with JavaFX.

In the future I will add other examples and I hope that the community will contribute other examples too. At the moment I'm working on an example using the Haskell-like pure functional language Frege and FregeFX.

If you like to add another example with your framework of choice (No matter if you are the author of this framework or just a user) you are very welcome. Just add an issue in the github project so that me and others know you are working on it and so we can discuss your idea. Or simply send a PullRequest :-)

I hope that the gradle build configuration I'm using at the moment works for your framework/language too. If this is not the case please tell me - I'm open to suggestions of how to improve the build process and project setup. You can find more information on how to contribute in the readme file. And of cause I'm also happy to hear if you think there is some information missing or the description could be improved.

To make sure that all examples are fulfilling the requirements I've added a set of TestFX tests. These UI tests are simulating a user interacting with the app. If you've never seen a little more complex TestFX test this might be interesting for you too.

I hope this project will be useful for JavaFX developers out there. Please tell me what you think :-)