JavaFX 2.0 BeJUG conference

History and status

The presentation started with a quick history of Java. How it started as a desktop application programming language. How that rich client facet of Java almost disappeared completely behind the Java EE web application years ago for economic reasons. And then how it may come back in a near future with frameworks like JavaFX 2.

But what is JavaFX 2? JavaFX 2 is “a modern Java environment designed to provide a lightweight, hardware-accelerated UI platform that meets tomorrow’s needs”. In this assertion, every word is important. And if JavaFX 2 may address tomorrow’s needs, today, it is still a work in progress. Only the Windows platform has attained the General Availability stage. Mac OS X implementation should get out of the dark in the next months and you can download a quite useable Linux implementation from OpenJDK sources. But unfortunately, iOS and Android implementations of JavaFX are not yet available. This is really unfortunate.

It is foreseen that JavaFX will replace Swing and AWT as a standard graphic library starting with Java 8. But that won’t happen before Java FX becomes JavaFX 3.

So, pragmatically speaking, JavaFX 2 must be considered as experimental at the moment (and that’s also what the demo done during the second part of the presentation confirms). It is the advice of the first presenter too : “wait until Java 8 and JavaFX 3 before reaching production with a JavaFX application”.

API

There are 2 APIs to JavaFX 2: the FXML API which is a declarative XML interface; the second API is a Java API similar to the Swing interface.

A big difference from the former Swing API is the ability to render HTML content through the use of the WebView component. This makes it possible to enrich a classical web application with behaviours (such as Near Field Communication or eID reader integration) that are only possible in a rich client.

The first part of the presentation is ended by a Hello World demo which looked to me a lot like the tutorials I’ve made with Swing. At least, JavaFX looks more polished than its predecessor and simple things seem simple to program.

Real-World demo

The real-world demo features healthcare software to manage patient’s dossier and made by the HealthConnect firm.

A lot of CSS was used to style UI controls. The CSS properties are proprietary to JavaFX (they all begin with -fx- …) but look similar to HTML properties.

The accent is put on the calendar and dropup (with auto-complete) controls developed and heavily customized by HealthConnect.

It is also put on the observer pattern which allows binding a UI control to a model property. Once done, every change on one of the UI or the model is reflected instantly on the other. Unfortunately, to achieve this, JavaFX 2 has created its own JavaBean-like API with, for example, SimpleObjectProperty and ObservableList.

There also exists a Task API to ease concurrency management while running service callbacks only in the main UI thread.

Here are the various lessons learned from the development of the application:

What has been easier with JavaFX 2?

  • great look and feel
  • customization thanks to CSS
  • the binding between the model and the view thanks to the observer pattern

What has been more difficult with JavaFX 2?

  • hard to change the default behaviour of controls
  • fighting against the JavaFX rules of engagement leads to weird results (but which framework doesn’t behave like that?)

Here are now some resources mentioned during the presentation:

I hope you enjoyed this third article. See you soon for the next one.

PlayFramework 2.0 BeJUG conference

So here is my second post. This time, I cheated a little. As I was sick at the conference time, I had to catch up with the recording of the presentation that BeJUG team put on parleys.com. Big thanks to them!

So, what is PlayFramework?

PlayFramework is a web framework. It features Java and Scala as programming languages for both controllers and page template. As you’ve probably already figured out from the terms I used, this framework is more action-based than component-based.

With the framework comes a philosophy.

First, everything is put in place so that the developper can keep focused on what he’s doing. Meaning that you can use only a text editor (or an IDE if you prefer) and a browser once the PlayFramework server has been launched. Every feedback the framework gives you (and it gives you plenty of feedback) appears in the browser. And every change you make in the code is reflected immediately in the browser.

Second, the framework uses a compiler to validate all your files (even page templates and configuration files). If there is a syntax error in your Scala or Java file, a compilation error is displayed in the browser with an indication of the error and the line it occured. This is kind of standard behaviour. Nothing special about it. When it becomes really cool is when you get the same type of error for your template pages with indications relative to the original file (and not the generated class). So here we get to something similar to what we can get with a JSP interpreter. That’s cool. What is really cool is that we even get the same feedback detail level for configuration files. That rocks!

Third, the framework tries to not fight the HTTP protocol. That means that it doesn’t hide the inner bits of the protocol. Quite the contrary. You will thus find methods to ease the usage of HTTP response codes, the usage of cookies, …

From the given demo, it really seems to be a framework easy to use and easy to learn. And as it doesn’t try to hide technical details of the HTTP protocol and the browser rendering, I have good hope that everything you know about web development is directly useable with this framework. Good point thus for a framework that lessens the amount of plumbing needed to get started and still succeeds to not get into the way.

After that first impressive demo, came a description of the Enumerator – Iteratee pattern. This pattern actually comes first from Haskell (http://hackage.haskell.org/package/enumerator). It is composed of:

  • iteratee: a data sink that consumes input values and generate a single output value.
  • enumerator:  a data source that generates input values (from reading a file, a socket for example) and is passed an iteratee.
  • enumeratee: a data transformer that read from an enumerator and provide transformed data to an iteratee.

Instead of controlling the information flow from the source, in this pattern it is the iteratee that is in charge of telling the enumerator if it wants to get more data or not.

That pattern is featured heavily in Play. You can use it for example to manage Comet connections (HTTP connections that “never” closes and that streams data to which the client browser can react in real time). You just define your enumerator on the server and tell him what callback method to call on the client when it has data to process. This really ease the concurrency management and allows the server to keep up with thousands of connections with a reasonable hardware.

The presentation ends with the show of the sample applications embedded within the PlayFramework 2.0 distribution.

This is only a small summary of the presentation. If you wants to have a look at it, you can watch the complete presentation on Parleys.com (http://www.parleys.com/d/3143 for part 1 and http://www.parleys.com/d/3144 for part 2).