Implement your own Redux for 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 shown 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 for 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 :-)


Reactive Programming and JavaFX - Article in german JavaMagazin

I’ve written an article for the german JavaMagazin 7.15 with the topic “Reactive Programming mit JavaFX” (you can find it here online:

In the article I’m introducing the reactive programming paradigm from the perspective of a UI developer. Reactive Programming is technique to escape from the so called “callback hell”. Instead of reacting to user events with callbacks (i.e. side effects on a global state) you define dependencies between time-varing values that will be updated automatically by the programming environment when changes or events are happening.

With its properties and data-binding API, JavaFX already has a good base for reactive programming.

One point I wanted to highlight in the article is the fact that you don’t necessarily need a functional programming language to do “Reactive Programming”. Of course the original work and research in the field of reactive programming was done with functional languages but it’s possible with non-functional languages like Java too (of course the syntax is far more inconvenient but thats a fact that apparently every java developer has resigned to ;-)). A relatively simple abstraction over the Observer design pattern is all you need, like it is done in the internal implementation of the JavaFX properties and databindings.

To make the programming easier there are also libraries available that can help to write JavaFX application in a reactive programming way. The first library I’m introducing in the article is my own Advanced-Bindings project that can be used for more complex bindings.

After that I’m using the really cool ReactFX library for composition of event streams. At the end I’m presenting the library RxJava which is obviously the most famous of the stated libs. In the article I’m showing how you can integrate a RxJava based service in a JavaFX application.


Generic repository for Java (Part 2)

In the first part of this series I was showing an interface for a generic repository and an in-memory implementation. In this part I will show another implementation with the Java Persistence API (JPA).

An in-memory repository is a good starting point and is handy during the development but at some point you need “real” persistence. One option in the Java world is the “Java Persistence API” (JPA). This blog post is not a JPA tutorial so I expect you to have some knowledge about JPA already. Furthermore I have to admit that I’m not a pro when it comes to JPA. Again: The things described here are working for me but I’m sure there are many improvements possible.


Generic repository for Java (Part 1)

Persisting data is part of most apps and there are several ways of doing persistence. In this blog post I’m sharing some of my techniques and personal oppinions. Maybe it doesn’t fit for everybody but it works for me and maybe this is helpful for some people.

When it comes to persistence my favorite is EventSourcing: Instead of persisting the current state of your data, only events of changes to your data are persisted. The current state can then be (re-)calculated from the events. In my oppinion this is the most natural and elegant way of handling persistence but, to be honest, it’s not the easiest to implement, especially in Java.

But this is another story. Today I want to further investigate persistence for use cases where EventSourcing is not an option and/or classical state-based persistence is needed. In such cases I’m typically using the repository pattern. The key of this design pattern is to define a common interface for persistence functionality that is independent from the underlaying persistence technique. For each specific persistence technique (for example a database, the filesystem or a cloud storage) an implementation of the interface can be provided. This way you can exchange the persistence technique without touching the rest of your application. Additionally this improves the testability because you can provide a mock implementation of the repository interface for unit tests.