JAXLondon 2011 - Some reactions

I only went to 15 sessions of the total of 40, but given that Day 1 had five tracks and Day 2 had four tracks, I think it was good going to be in a session at every slot. Sadly though there were at least 10 other sessions I would like to have been at.

The four keynotes were reasonable, with a nice mix of motivational aspects and informative aspects. Nothing really stood out though, except perhaps that in Simon Ritter's summary of the road map for Java, JavaFX on Linux is not due till half way through 2013, which shows how much the JavaFX team and Oracle care about being truly multi-platform.

Given my main interest is concurrency and parallelism, I took in all the session related to that topic, along with the Java 8, 9, 10, . . . summaries. I didn't hit the Android track.

Of course I have to mention my session: "Just Keep Passing the Messages", slides here. This was really a rant against unthinking use of shared-memory multi- threading as an applications programming technique, and a plea for applications development folk to learn about and use higher level models such as actors, dataflow, communicating sequential processes (CSP). I plugged GPars as a framework that Java and Groovy programmers can use now to do all this, so they don't have to wait.

All the other 10 sessions were good, worth attending, and I enjoyed them. The three "stand out" sessions for me though (other than mine :-) were "An Introduction to Neo4j (and Doctor Who)" by Ian Robinson, "JavaFX 2.0: Great Interface in Java" by Simon Ritter, and "Understanding the Disruptor, a Beginner's Guide to Hardcore Concurrency" by Trisha Gee and Mike Barker.

Ian Robinson managed to educate everyone attending in the subtleties of studying Doctor Who, including retcons, whilst really showing that Neo4j is really a unique form of database management system. He focused mainly on daleks, which was fine as they are clearly a common enemy! Ian mentioned that the daleks first appeared in 1963-4, which came as a bit of a shock, as I remember watching those episodes at a friend's house the first time they were shown.

Simon Ritter's presentation of JavaFX 2.0 showed for me that it was the right decision by Oracle to drop JavaFX as a purely script based system and to transform it into a Java API. This is not because I want to code UIs in Java, but because it makes it an open system that works well as an integral part of the JRE. Simon's Java examples were fun, and worked well, but showed that Java is not the right language to actually write UIs with. I will be using Groovy most likely. The point is that there is not one fixed language to write JavaFX 2.0, and soon JavaFX 3.0, UIs with. JavaFX 2.0 seems a splendid successor to AWT and Swing. But of course AWT/Swing UIs can incorporate JavaFX bits, so people can use evolutionary rather than revolutionary development. Personally I will just dive straight into JavaFX 2.0, but only when the Linux version is released so that UIs can be platform independent: Windows, Mac OS X, Solaris, and Linux.

Trisha Gee and Mike Barker's session stood out since above all it showed how to do some real science when engineering a solution to a problem. Their problem is to process vast numbers of messages with various transformations of data needed. They showed, via experimental evidence, that standard approaches to concurrency and parallelism we insufficient to the task. Indeed employing parallelism made things slower for their problem compared to a simple single threaded solution due to all the overheads associated with the concurrency and parallelism tools. Here we are not just talking of Java and JVM overheads we are talking of JIT generated assembly language and processor cache line management. I am used to C++ folk worrying about cache lines, it was inspiring to have Java folk seriously worrying about these things entirely appropriately. They then showed how they had analysed various data structures, reasoning with the Java memory model, and experiments probing the JIT code generation, to write a lock free ring buffer that is the data structure at the heart of the Disruptor. Opinion not necessary, the experimental data shows they have been massively successful.

I will be submitting a session proposal to JAXLondon 2012.

Copyright © 2005–2020 Russel Winder - Creative Commons License BY-NC-ND 4.0