Red Hat
Dec 5, 2012
by Carlo de Wolf

It has been almost one month since Devoxx 2012. I think that is a good time to do an inventory of what I recall of Devoxx. It would also serve as a pointer for other people that I may have forgotten something important.

Hackergarten

I saw Dan and a lot of others working hard on Hackergarten Overdrive! They made some very good progress. Ivan made the astute observation that it was mostly mentors hanging around and not so much developers. Maybe it was because of the open agenda? Because the last presentation of Devoxx given by Adam Bien was essentially a hacker marathon in itself and very well attended. Although there we missed out on the real hacker interaction. What if we set forth with an agenda and thus attract specific interested parties?

 

As for myself we got a small hacker fest going with a customer to upgrade from AS 7.1.1 to EAP 6.0.0. For an application itself the upgrade is a breezer. Just drop the application onto EAP 6.0.0 and you are done. But in this instance we also looked at configuration changes.

 

The first plan was to migrate these changes into the new config file, but that would have taken us a couple of hours. So we went for plan B:

  1. install EAP 6.0.0
  2. copy config file & application over from AS 7.1.1 to EAP 6.0.0
  3. boot it up
  4. have beer

 

Lo and behold, it booted up perfectly on the first go. So the upgrade from AS 7.1.1 to EAP 6.0.0 was done in 10 minutes and the last 20% of this plan took more than 80% of our time (of course).

Goodbye JBoss AS

The question of why is finally boiling down.

But I'll reiterate it one more time: a lot of people say we are running on JBoss or we support JBoss. While they actually mean, we are running on JBoss AS and we support JBoss AS. JBoss is the brand name and not a piece of software. Hence we are renaming the piece of software as AS by itself did not pass legal checks.

 

What will the new name be? Personally I like Petasos as a refence to both a (red) hat and god of middleware.

 

Anyway the voting is closed. I do not know any of the results, so don't ask me. Just like you all I have to wait for the announcement to come.

JSR and Expert Groups

I like the discussion that happened in the EG BOF. In terms of how we can further enhance the process to allow community visibility and involvement.

 

One important issue that was raised is the lack of a source control system for both the spec itself and the API. Now the burden of keeping spec and JSR website up to date is fully on the spec lead. With a good SCM this burden could easily be shared. Picture filing pull requests to the spec. Hopefully each EG will setup a SCM to tackle this soon.

 

It also raised the issue that API classes are currently coded with vendor specific implementations. By having the SCM open for everybody we could actually code out vendor neutral API classes. Personally I don't care about the licensing issues that would pop up, that's a byproduct of the world we live in.

Java 8, Lambda & parallelization

And of course there was a lot on Java 8.

 

I think we'll need more for parallelization then what was presented. Especially to factor into existing applications.

But then again I missed some sessions, so maybe it was covered in there.

As AS 7 has proven paralizing stuff properly can make a huge difference performance wise.

OSGi and modularity

I would call this: the upcoming maintenance hell. Having multiple versions of components to maintain without any guard of restricting such version usage can explode the maintenance burden of a system.

 

Running multiple versions should only be considered as an escape or if there is a real feature requirement. An example feature is running JBoss Data Grid on top of Enterprise Application Platform. JDG uses a feature enhanced Infinispan (with different configuration) as opposed to the one used in EAP clustering. So by isolation it JDG has no impact on the cluster functionality of EAP.