We don’t attend Devoxx for eating, do we?

In 2013 I attended the Devoxx Conference, the last 3 days. Going to both the university and conference causes topic redundancy that, in my case, would result in brainfreeze and lack of attention after 3 days.

The overall Devoxx experience is usually one where I drink coffee from dawn till dusk, pick up some tools, books, jsr’s . Old or new architectural ideas I somehow missed out on during the year and will put to good use in the next year, drink beers in the evening and eat bad food during the day (except for the fruit, that’s good).

Yes it must be said: Devoxx usually great Java and Java related content but no one probably knows a conference where there is that much complaining about the food. Some lone ranger dares to claim it’s good, I pity that rangers and wonder how bad his or her food is at home. Then again, organizing lunch for 3500 people probably isn’t that easy. But enough about the food!

We don’t attend Devoxx for eating do we? We go there for Java!

Although to be honest during most sessions I had the following thought more than once: ‘please, speaker, go on to the next slides, we got it’. Was it all to simple? Yes perhaps for me it was, I need to start looking into different concepts of absorbing new stuff and ideas. That aside, what luggage did I really take home?

I remember 2 not ignorable facts! First, everyone is using angular.js in their demos. It is either really great with good performance and awesomely usable or someone pay all presenters to use angular.js. Anyhow, if you haven’t checked it out you should do so.
Secondly almost every Java developer I talked to is really waiting for Java 8 (unless it was a scala dev, they have lambda stuff already). Java 8 is a release we will all remember. And probably companies will be upgrading from older version to 8 faster then from 5 to 6 or 7. It’s a release they will bother upgrading to. Let’s hope all frameworks are 8 compatible by February 2014.

A tool I’ve had heard about before but actually never took the time to look at is Lombok. This nifty tool reduces getter/setter/builder/equals/hashcode/constructor boiler plate code of classes to null. Yes you’re reading it right zero. By plugin in a byte code generation tool that reads some annotations during generation time, the above mentioned methods are created for you. Thanks to plugins for the major IDEs you instantly see the changes in your IDE too. Since November I’m actually using it, and it’s great! Read more on it’s greatness at RebelLabs.

The talk I personally picked the most from was called ‘Fault tolerance made easy’ describing a couple fairly easy techniques to allow your applications to fail faster on errors and so giving better(faster) feedback to users, thanks to failing fast. A quick example that seems so logical if you read it, but not much people use it. If a resource becomes unavailable, from then on you know that it is, so why bother trying to call it again? Fail before you call it and in the background check when it becomes available again, saves time and needless connection or read attempts. I’m not going to copy past his slides, instead take a look yourself

or even better watch it here on youtube.

This was the session where I wrote down the most data on paper.
All things were remarkably easy and some of the patterns I had used before. But thanks to this presentation I discovered them again. If you think a bit further on each of the cases, there are numerous ( fun ) options for fault tolerance code. A couple books where mentioned, of which you should at least read release-it  (Yes indeed it’s a nice book). Many thanks to Uwe Friedrichsen for this nice session.

Of course the obligatory lambda talks could not be left out! That’s what we’re all waiting for in Java 8 no?
Lambdas will simplify our life. I’m mainly looking forward to the stream API for iterating over collections. No more for each loops and optionally parallel execution made easy. However I personally like writing this concurrency boilerplate code, I have fun when writing it, but when writing mundane applications it will ease development.

If you like profiling and benchmarking things, you should take a look at Java Microbenchmark Harness, a great tool to microbenchmark your compiler as Alaksey Shipilev showed. Although some say that microbenchmarking is evil, it can give you great insights on how/when your compiler is doing stuff.

Further on there were also a couple sessions about reactive programming, closely related to how Play! (and Akka) and thus Scala is working. I somehow had the feeling that these sessions were too much Typesafe (the company behind it) related but they did make a valid point. Reactive program is a way of programming that lends itself very well in highly concurrent application models. Just like it can closely relate to stateless and functional programming. I’m not saying we should all start to embrace reactive programming and scala as the solution for everything. Not everyone is running things on 64 core hardware, or are you?
There were other languages on the JVM talks but I didn’t go to see them all. What I do know is the good thing of all these JVM languages, and the for them fitting programming models, is that they enrich and help shape the future of Java. The good things from these languages somehow make their way into next versions of Java, albeit some a little slower than others.

So this is what I personally took home with me from Devoxx 2013. I feel like it’s not that much, for 3 days of conference it might have been more. ( But it does result in to lengthy posts! )

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.