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
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,
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.