Using your SSL certificate for your Spark web application

I’ve fallen in love with Spark recently. Being unexperienced with web development, I stumbled upon Spark when I was looking for a small framework for setting up a simple web application based on Java. My learning curve has been steep and my first website (consisting of nothing but a simple form) is running smoothly.

One issue I had to deal with was using my domain’s SSL certificate (proudly sponsored by Let’s Encrypt) for the integrated web server that comes with Spark. As you can read here, a keystore and a password need to be specified in order to achieve this.

Alright, nothing easier than coming up with a password, but how do I set up a Java keystore (.JKS) that uses my certificate? A quick Startpage search directed me to Maximilian Böhm’s tutorial on JKS and Let’s Encrypt certificates.
I could skip step 1 as I had created and installed my certificates already. For step 2, I needed to locate the directory in which my Plesk installation stored the fullchain.pem and privkey.pem files. I found them in:

I copied them to a temp directory to make things easier, and then ran the following command:

After typing in and remembering the password, the resulting pkcs.p12 file could be used to create the JKS file as described in step 3:

Here, SRC_STORE_PASS is the password chosen in step 2. Make sure to remember and distinguish those three passwords! Or use the same phrase for all of them.

The result was saved as keystore.pks. I changed my Spark code accordingly:

and put the file next my JAR. Done.

Update 2017-09-02: Here’s a script that updates the keystore entry (e.g in case the existing SSL certificate has been invalided and a new one has been created).


A Potential Pitfall with the TextFormatter Class in JavaFX

A common use case for the TextFormatter class in JavaFX is a text field that should convert any lower-case character input into an upper-case character. This can be achieved easily by defining a filter for the text formatter as described here. A straightforward implementation could look like this:

This implementation comes with one pitfall, though. When the (German) user types the character “ß” into the text field, it will be converted into “SS” because that’s how Germans roll. So the resulting string is one character longer than the input string. Why is this a problem? Well, the cursor position will be between the two “S” characters after the conversion:


When the user types in the next character, it will be inserted between the two “S” characters, not behind them. Bummer.

Luckily, the masterminds behind JavaFX give us the tools to correct this unfortunate behaviour since the change object that the filter works on allows for setting the anchor and caret position in the text field. We need to correct them by the difference between the string lengths before and after the conversion:

This puts the cursor at the end of the string no matter how many “ß” characters the user types in or pastes into the text field.

Can There Be Too Much of a Good Thing?

I recently worked on JavaFX UI code that was new to me. In order to extend the existing UI by a simple label, I needed access to a bean of the underlying data model. Much to my surprise, I had to dig deep to find it hidden under multiple layers of wrappers. This was the data structure:

A bean wrapped in a BeanWrapper wrapped in an ObjectProperty wrapped in a WrapperPropertyProxy. Quite impressive.

Wow. Clearly, someone tried to satisfy their fetish for wrappers and indirection. I’m going show this image to the next computer science student I come across and ask them how many design (anti-)patterns they can see.

Using FXForm2 with EMF Models

Based on these considerations from July, we gave FXForm2 a shot for generating forms from EMF models. It worked quite smoothly after we wrote the factories that defined how the custom data types used in our models should be displayed.

We found a few things that are worth noting:

  1. Using Java Bean Validation
    In order to validate our EMF models using the Java Bean Validation API (JSR-303) that comes with FXForm2, we wrote wrapper classes for those model elements that we wanted to add constraints to. We decided to not touch the generated code.
  2. Using another validation implementationFXForm2 can use any implementation of JSR-303. Using the Hibernate implementation is suggested on the FXForm2 website, but we found it easy to supply our own implementation based on EMF’s validation features such as the Diagnostician class.
  3. Validation philosophies
    When you enter an invalid value into a field, FXForm2 won’t update the corresponding model attribute. The value you see in the form differs from the value in the model. The model thus always has a valid state.EMF validation typically works in a different way: you start the validation operation only after all model values were set. This allows for invalid states of the model.
  4. Dynamic beans
    An open issue
    seems to be (as least for us) the handling of a String-to-String Map attribute inside an EMF bean class that stores user-supplied key-value pairs which should be displayed as regular attributes of the bean. Antoine suggested a solution based on a custom control (with a factory and a skin), but it comes with a different visual appearance for the user-defined attributes. This is work in progress.

GUI Generation with JavaFX

Recently, we have had a look at JavaFX libraries for generating UIs in a dynamic way. The idea is that we have a data model (a JavaBean class, an EMF model class, a model class with JavaFX properties,…) as input for some GUI builder that takes the model and generates a matching user interface with bindings between the model and the JavaFX controls. In a perfect world, this library would allow us to use a variety of data models and to customise the generated user interface.

We have had three candidates (all open source). As we use EMF a lot, two of them are based on EMF models.

1. FXForm2

This pops up early when you are looking for UI generation libraries for JavaFX. As the name implies, it is meant for generating forms from model beans.

A sample form generated by FXForm2

The main features include:

  • Automatic form generation and binding to bean properties
  • CSS support
  • Bean Validation handling (JSR 303)
  • Fields reordering and filtering
  • Tooltips
  • Localization

It takes three lines to add a generated form to your JavaFX scene graph:

2. EMF Edit for JavaFX

This library has a broader scope than FXForm2 as it can generate an entire RCP application with a sophisticated visual model editor rather than just a couple of form fields. Or you can define your own controls and easily bind your EMF model instances to these controls, including support for drag & drop and undo/redo commands. An example of a user interface based on a “Contacts” model can be seen in Tom’s video from the link above.

A sample application using EMF Edit for JavaFX

3. EMF Client Platform

This takes the idea of EMF Edit one step further. As the ECP website says:

The goal is to provide a one-click application based on a given EMF model. Besides the EMF model, no additional components have to be developed or generated.

A sample application as generated by the EMF Client Platform

So when you have your EMF model, you are only one click away from a complete client application with a model explorer, an editor, a persistence mechanism, and a couple of other nice things. The editor for the model attributes is similar to the data form generated by FXForm2, but it is embedded in an entire application whose pieces are customisable and extensible.

The bad news is that there is currently no JavaFX support for ECP.
As Tom Schindl has pointed out in the comments section, there is a first version of JavaFX support for ECP in one of the development branches of the e(fx)clipse project. See here.

4. Summary

We have not found the perfect solution yet. FXForm2 has a promising approach for easily generating forms, of which we are going to have a lot in our final product. It requires some tweaks to make it work with EMF models but that is a small obstacle. What worries me a bit is the maturity of this library: the latest version is 0.2.2. So is it ready for production use? Well, there’s at least one real-world application that uses it.

EMF Edit is a very powerful framework but does not generate controls on the granularity we require for most parts of our application. It will certainly be of use for fancy features like drag & drop and the command stack. Maybe we can combine its strengths with the power of FXForm2 for generating really rich forms.

The EMF Client platform has a very appealing one-click approach but it lacks support for JavaFX. Once this limitation is gone, we may give it another look. A major question will then be how far we can customise the basic layout of the generated application which by default is very different from what we have in mind for our user interface.

Designing Interfaces with JavaFX

Good design makes you happy. I was happy when I first saw an iPod, and even happier when I first held it in my hand. Sometimes, you will not notice the positive effects good design has on you, but you will always notice the effects of bad design.

I’m a software developer, not a designer. I’ve known that ever since the late 90’s when I repeatedly failed at impressing my friends with my one-minute Flash intro for my two-paged personal website over at Geocities. Why haven’t I learnt my lesson and still deal with visual design today? Because I believe a good visual design is essential for any software that has a user interface. If you don’t believe me, read what Ben Northrop wrote about the Halo effect.

Designing a great user interface is hard, in particular when you’re more excited about your domain models and your test coverage of 101%. Unfortunately, even smart developers can write bad user interfaces, as Karsten Lentsch explains in this Jax session (in German). It takes a lot of time, training, and user research until you come up with a user interface that doesn’t suck and that is tailored to your user’s needs.


If you’re lucky, you have a thorough and well-organised process for that. If you’re even luckier, you work with a professional user interface designer who can do all those things for you. That’s also a great way to find a scapegoat in the end, by the way.
But even working with a designer doesn’t save you from analysing your information architecture and from organising your application content. There’s still a lot to do.

And this is what I’m currently doing. My job is to develop a user interface for a client-server business application offering a compelling user experience. Here’s what I have so far:

Oh wait! I have some fantastic tools, too. They are centred around JavaFX as we saw the potential of this platform pretty early in our project and it has not disappointed us since. JavaFX supports the design process by its separation into layout (FXML), logic (controller classes), and appearance (CSS) tools. All of these can be tied together nicely with our underlying Eclipse rich client platform thanks to Tom’s e(fx)clipse project.
There’s nothing like a good tool chain. Well, a good design maybe.

So I know JavaFX allows me to develop great user interfaces, but how do I actually do it? How do I put the pieces together? This is the main question I’m going to ask my designer and myself again and again over the course of the next weeks and months. We have a general layout for our application window, which is fairly common in other applications, I would say, but one of the first things to decide now will be the navigation. How can the user go forward and backward in our application? How does she know where she is? And how do we tell her what else there is?
Exploring these questions is going to be part of my next blog posts. Stay tuned.