Devoxx

On wednesday, I went to Devoxx (formerly JavaPolis).

First, breakfast as usual; then the keynotes session about JavaFX and the on-site RFID experiment.
It was the first time I heard about JavaFX. It seems to be the next Flash and it looks cool. I especially liked the fact that it runs in a JVM process separate to that of the browser so that one doesn't slow down or blocks the other. This also makes it possible to drag JFX applications out of the browser and run them standalone.
The RFID presentation was done by an ill-prepared IBM suit who, having seen the venue, seemed to have managed to remove his tie and loosen his top shirt button only barely in time. At the venue, three (sponsor) companies worked together to provide RFID-containing badges, equip all rooms with scanning portals and supply hardware and software for tracking badges and creating statistics about the attendance of various talks.
Instead of telling about anything Java-related on this Java venue, they went on about hardware, antennas, limitations of RFID, etc. Also, instead of doing one comprehensive talk, the three companies each did their own presentation and together they went 15 minutes over their alotted time.
What I missed in this keynote: the Java aspect and a real-time view of people moving about at the venue (especially those leaving the RFID talk; there were plenty).

Next, I went to the Hippo talk. Hippo is a JSR-170 compatible ECM and CMS, using Apache Jackrabbit somewhere inside. From the presentation it looked nice and user-friendly, but when I asked whether Hippo could be deployed on top of an existing Jackrabbit repository, they couldn't give me a satisfying answer. I guess I'll have to check out that for myself.

Lunch was a disaster: after queueing for ten minutes, they were out of bacon sandwiches (I don't eat cheese and I don't like fish on a sandwich), so I moved to another queue. After standing in line for another ten minutes I finally had my sandwich, but they were out of soup. And by that time they were out of soup everywere.
The organisation was very proud to announce the venue was sold out for the second time in a row: 3200 people attending. Is it that hard to multiply, say 250ml of soup by 3200 people and end up with enough for everyone?

After lunch, I went to the High Performance Java talk, which proved not to be a good start of the afternoon. The (overacting fake-jovial) presenter (Iran Hutchinson) started with a five-minute joke about his first name before going on about OSGi and how it should be used and what some of its pitfalls are (managing multiple threads in a single bundle, apparently). He also briefly mentioned Caché, some kind of high performance database that is accessed like a multi-dimensional array. This should have been the core of his talk, but I went away with the knowledge that the Knopflerfish OSGi implementation offers a GUI (something that I would have liked to have seen in the OSGi-specific talk I attended last year).

Next up, Scala. Having a functional programming and language design background, I was a bit interested in how functional programming could be implemented in Java. Simple: by breaking source compatibility: Scala is a standalone language that is compiled to Java bytecode.
They didn't go into implementation details, they just showed some basic constructs and how they are translated to Java.
Since Scala converts infix operators to method calls from left to right, operator precendence looked a bit fishy. Unfortunately, they only showed simple operators that didn't require precedence and there wasn't time for questions.

One of the few things I understood from the next talk was that Scala has a bit of a problem with mathematical expressions; well, isn't that a coincidence?
The core subject of this next talk was about cross-language development: using different languages in a single project: Java, Ruby, Groovy, Scala, ... The two guys presenting were very enthousiastic, but the whole sounded like the dialogue was provided by a Russian-to-English translator tool and I'm afraid my brain just shut down in horror at some point. All I know is that if I ever need multiple languages in a single project, I have to take a look at IntelliJ IDEA.
My brain did wake up on the intruductions of new terms such as 'camel humps names' (CamelCase identifiers) and the Elvis operator: '?:' ('when your head is turned ninety degree').

The last talk of the day was interesting again: "RESTful design - Patterns and Anti-Patterns."
REST is an architectural style (Roy Fielding's orignal definition) or "the web used correctly." "XML without SOAP" is one of the worst and most innacurate popular definitions of REST.
There are five requirements for REST:

1. Every 'thing' gets an ID (eg a URI).
2. Link together as much 'things' as possible.
3. Use standard methods (eg GET, PUT, POST, DELETE).
4. Allow for multiple representations of the same 'thing' (eg human-readable HTML, machine-readable XML, or both together in the form of XHTML). The representation could eg be chosen by an Accept header in an HTTP call.
5. Communicate statelessly

Some anti-patterns:

• Tunneling through GET by using the same base URI with different methods specified in a query part.
• Tunneling through POST ('the SOAP way') by using the same base URI with different methods specified in an XML body.
• Ignoring caching; the server should use cache control headers and ETags.
• Ignoring response codes.
• Misusing cookies: using them to identify state is wrong.
• Forgetting hypermedia by not connecting resources and representations together.
• Ignoring mime types; use the correct mime type for every resource; use the vendor namespace if necessary (application/vnd.XXXX).
• Breaking self-descriptiveness (when the manual of how to use your service becomes bigger than the service itself).

Some REST patterns:

• Use collection resources where you provide links to individual resources (eg a GET on '/products' produces '/products/apple' and '/products/pear').
• Page your collections when the list of links become too long (eg with a query in the URI).
• Don't worry about URI design or hierarchy, opaque URIs are fine; linking stuff together is more important than the way links look like.
• Create resources by POSTing to a collection.
• Polling to generate notifications for changes is not bad as long as caches are used properly.
• Externalize server cache by putting the cache operation in a proxy that handles the cache and ETag headers.

He did go a bit fast from time to time, but this presentation was a good introduction to REST and a starting point to get to know more about it.

Dinner was even more disastrous than lunch: they ran out of french fries when only about two thirds of the attendees got their tiny helping. Hearing it would take at least half an hour for a new supply to arrive, I went home hungry.