Last week I attended JAX '09, the Java User Conference in Mainz, Germany.
Or rather "conferences", because once you're there JAX is indistinguishable from something called SOACON and the Eclipse Forum Europe, which officially take place in parallel.


Compared to last year's Devoxx (a.k.a. JavaPolis) and certainly events like FOSDEM, the mood at JAX seemed rather subdued. Since I hadn't been to JAX before, though, it's hard to say if that was the recession biting or just the norm for this conference.
I overheared one of the organisers mention that attendance was down on previous years, though. Certainly, for a conference of this size - 08:30 to 22:15 daily, with up to 12 concurrent sessions - it felt a bit empty. The "expo" area looked especially quiet.

Apart from some of the "usual suspects" (Neal Ford, Ted Neward, Peter Kriens; SpringSource, JBoss, dynaTrace), the vast majority of the audience and exhibitors were German developers and consultancies, respectively, giving the conference a strong "national" feel.


Buzzwords at this year's JAX (coinciding, unsurprisingly, with the conference's "Theme Days"):

Slightly disappointingly, these were all things that have been around for a while.


  • Web application development in Java
  • ESBs
  • Cloud


Ancient Philosophers and Blowhard Jamborees

Neal Ford's Ancient Philosophers and Blowhard Jamborees keynote was an entertaining, as ever, look at software development's past, present and future.

Neal laments our continuted inability to learn from the past - our blissful ignorance of software development's "lore", as he put it. As a result, we not only keep reinventing the wheel; instead of tackling the actual core problem at hand, we waste a lot of time and energy grappling with enormous white elephants architectural patterns, whose complexity is essentially peripheral to the issue to be addressed.
Whenever we're struggling with SOA, ESB or one of the other Rube Goldberg devices enterprise middleware solutions, we're paying, in his words, "complexitax". And our ignorance is keeping the tax rate high.

Perhaps to underline the message that we urgently need to become more aware, critical and, ultimately, better programmers, Neal pointed out that, if we don't, Chindia (ThoughtWorks-speak for the China/India juggernaut) will. They definitely have the capacity: as Neal mentioned, India's top 1% = 11,298,661 people.

That certainly sobered everyone up a bit.

Fette Maschinen brauchen schlanke Software


Fette Maschinen brauchen schlanke Software ("Heavyweight machines need lean software") was Klaus Alfert's take on the impact of multi- and massively multi-core architectures on our future programming styles and requisite skills.
Using the well-known graph of Amdahl's Law to demonstrate that additional processing units won't give us extra performance just like that, he posited that Von Neumann architecture itself, with it's mutable memory cells, is the root cause of many of our concurrency struggles.
Referring to John Backus' famous Turing Award Lecture, he singled out three approaches as key in the quest for safer, simpler concurrent programming:

Spotlight: Agile Documentation

Uwe Friedrichsen gave a interesting talk on how to approach documentation requirements in an Agile project. Some key points:

  • Production & maintenance costs consume 85% of a project's budget. Compare this with Agile's focus mainly on the development phase.
  • A complete product is more than just software; maintenance often relies heavily on documentation, for instance. But many "standard" documentation templates comprise 1000-1500 pages - that can't all be valuable.
  • The purpose of documentation ultimately is answering users' concerns, so good "stakeholder engineering" is critical.
  • Given changing requirements and functionality, it doesn't pay to start producing documentation too early - do ensure negotiate structure and content are agreed upon, though.

Slides are only available in German, unfortunately.

Spotlight: OSGi New & Noteworthy

Coming up in OSGi 4.2, amongst others

  • Service Hooks
  • (updated) Declarative Services

In the pipeline are also

  • Distributed OSGi
  • Transactions
  • JPA
  • more J2EEy stuff

"A Component Model for OSGi" (a.k.a. RFC 124 a.k.a. Spring DM) doesn't appear to have made it2, even though it was mentioned in the last early draft. For a quick summary of the original early draft, have a look at Mirko Jahn's blog post.

With support for Enterprise Java development coming more and more to the fore in OSGi, Kai Tödter and Heiko Seeberger's comparison of the current DI offerings was timely. Martin Lippert's slides (from another talk) contain some further examples.

The reference implementation of Distributed OSGi is being provided by CXF.


Sprechen Sie Deutsch?

By far the most surprising realisation came when I walked into the first talk and discovered that it was in German. Fortunately for me, that's my mother tongue, but international visitors will have had a somewhat ruder awakening.

This was all the more surprising given that I don't recall seeing an explicit mention of this anywhere on the conference website, during the registration process or even on arrival!

OK, the summaries of many presentations were in German, but on the German version of the site that was hardly surprising. One might say that the fact that the abstracts were in German even on the English pages should have served as a hint, but 9 out of 10 times that simply means that they simply didn't get round to translating it, in my experience.

To be fair, the Eclipse Forum Europe talks were all supposed to be in English (hardly a surprise for a conference with Europe in its title, I'd say).

However, at least one of the presenters, when asked by a Greek former colleague of mine to please switch to English, responded that he'd only heard about that requirement late at night on the day before his talk, and thus wasn't prepared. Hm.

To cut a long story short, I would simply expect all presentations and materials at an international conference to be in English, and I found JAX highly unprofessional in that respect. I'd be curious to hear what any of organizers would have to say about this.

Working Offline

Pleasing as it is to see nations refusing to live up to tired stereotypes, some aspects of the organisation could have done with a leetle more "German efficiency".

Before I am accussed of nitpicking, is it really that unexpected that attendees at a software development conference might be bringing portable devices, that may require power sockets to be recharged? Or that, in today's networked world, these attendees may wish to connect to the internet?

As it was, most venues had barely a couple of coveted rows with extension cords, and in some there was no power because the fuses blew (to be fair, this was quickly addressed as the week progressed).
With respect to connectivity, the Wifi connection, on the rare occassions when it was up, was so slow it was barely distinguishable from being offline. So much so that most presenters crawled through the online portions of their presentations via GPRS, rather than risking a wireless connection.

Not big things, really, but they stick in one's mind.

PS: To all the Dutch readers, have a great Queen's Day!


  1. If you're interested in STM implementations in Java, take a look at Peter Veentjer's Multiverse or Deuce. Clojure and Haskell both have native language support for STM.
  2. See Eric Newcomer's comment below.