Another Java technology blog from a developer far away from home

Category: Java

We recently migrated our platform towards Kubernetes. That’s for sure one of the best move, technologically speaking, that we’ve ever done. It provides stability, scalability, service discovering, centralized configuration, rolling upgrade… the list could keep going.

When you move to a platform for automating deployment and scaling like Kubernetes/DCOS, one of the things you absolutely need to get right is a proper implementation of health checks (liveness and readiness) and a graceful shutdown of your application (on top of compute resources, but that’s another topic).

At Skiddoo, we use the Play Framework for our REST API. Before building it, no one in the team had worked with this framework previously. But the reactive and stateless orientation of the framework made us believe it was the best choice if we wanted to build a lightweight and scalable application. Because we all come from a Java background, we choose naturally the Java version of the framework.

I could say a lots of good things about Play (JSON as first class citizen, asynchronous I/O..) and some annoying things too, but today is about Akka. So why am I talking about Play ? Because Play has been built on top of Akka (and other technologies). That makes Akka a potential first class citizen for every application using Play.

Until recently, we were only using Akka for its scheduler:

Akka.system().scheduler()

It was a solution for us to schedule some background tasks to be run repeatedly at a particular frequency (some of those tasks should have probably been a different independent service, but that’s another story).

And recently, we decided our API was doing too many things, it was time to refactor some services and pull them out of the Play application. As a start, we pulled out our tracking system (track all the flight searches made through our API to provide statistics to other teams, marketing for example).

I will assume you’ve heard a little bit about Akka and you have a global idea what it is about. My main goal was a service I could start/stop without impacting the other services communicating with it, and without losing any information.

At Skiddoo, we were very excited about migrating from Java 7 to Java 8. We have the chance to be able to move forward very quickly and easily with the latest technologies. We’re using the latest play framework version, and the use of lambda feature, combined to the stream from Java 8, felt like the natural next step to us. I was in charge of this migration. And, you might think it’s just about updating the JDK, recompiling, updating the JRE on the server and push, well it’s a little bit more than that.

First, it all started locally on my own computer. Before modifying anything on our Jenkins and staging environment, we wanted to make sure all the projects were, at least, compiling on a local machine with the latest Java 8 version. Because it might not, for multiple reason, let’s just take one as an example.

The Guava’s aficionado have been dealing with the concept of Optional for a while (since Guava 10 actually, it’s been 3 years). As usual, I’m not going to talk about how to use Optional, I’m more interested in the way Google implemented the concept, the Java 8 implementation and the differences between the two of them.

It took two years and a half to feel this gap in the JDK, and the choices made by the JDK expert groups are interesting in terms of implementation but also naming convention.

But let’s start with the Guava implementation.

Guava

Optional is an abstract class, implementing Serializable. It might look like a small detail, but it’s not, I’ll come back to this point while talking about the Java 8 implementation.

Java 8 brought us the lambda expressions (and the adepts of functional programming said amen). It was possible to approach the same concept before Java 8 by using the anonymous classes, but it was very verbose. They call it a “vertical problem” (using a lots of code lines to only represent a single call to a method, for example).

I’m not saying lambda expressions are going to replace the anonymous classes, it will not. A lambda expression can’t have any field or multiple methods. The only situation where a lambda expression can replace an anonymous class is when the anonymous class implements an interface containing only one method.

Anonymous class !== lambda expression

Lambda expressions are not just about wrapping a “single method anonymous class” into a more readable syntax. They are actually different objects behind the scene in many point of view. Whether in terms of compiling, syntax or execution. Let’s dive into it.

Yes, I will talk about enums again, I find these guys fascinating. And I’m one of these people who loves to know what’s happening behind the scene, to scratch the surface and (reasonably) go as deep as I can.

So you’ve heard about HashMap or HashSet right ? It turns out they have brothers (or sisters, up to you). They are called EnumMap and EnumSet, and they also extend AbstractMap and AbstractSet. When I discovered this, I obviously asked myself, why did they do this, how does it work ?

As you can imagine they are dedicated to be used with enums only, the enum being the key. So let’s go deep into the OpenJDK implementation. I’m not going to talk about the implementation of the HashMap (or HashSet), they are plenty of posts about it on the internet. I’ll start directly with the explanation of EnumMap and EnumSet because I never found any implementation’s explanation.

Since Java 1.5, the language includes the enumerated type, everybody knows that. But these guys are offering a very powerful tool here, too often used in the old way because we don’t always realize we’re dealing with a proper Java object.

Where languages like C are just offering an integer representation with enumeration, an Enum in Java is an object with all the characteristics we know about the Java objects.

Behind the scene

So what’s happening when we declare an enum in Java ? Let’s take an enum called AdjustmentType for example, which describes the operation we want to apply on a price:

public enum AdjustmentType {
INCREASE,
DECREASE
}

Because of the enum keyword, AdjustmentType becomes implicitly a final class extending the java.lang.Enum abstract class, the call AdjustmentType.class.getSuperClass() would return the java.lang.Enum class.

Welcome to my (first) blog ! I never had a blog, not that I never thought about it, it’s just I never really found the topic and the content. But recently, I was talking with @Jaiew, my co-worker at Skiddoo, about how fascinated it was, the way some Java classes have been implemented in OpenJDK by Joshua Bloch (I spend a lot of time reading the JDK source code), and he told me I should write articles about it. I realized he was right, it could potentially be an interesting subject to other people too, I finally got my topic.

Here we are today, a VPS, a domain, some installations, configuration of PHP5, WordPress, we’re up and running ! So yes, it will be another blog talking about Java, but more the Java “Behind the scene”. I can’t promise it will only be this, it will probably have some stuff about being a software engineer at Skiddoo or posts about iOS development, my second main development skill, and why not talking about Sydney this amazing city ? I guess it will be about me in the end, but I’ll do my best to get everybody to learn something at the end of a post. So let’s start immediately with this one:

Did you know you can find the magic number 0xCAFEBABE (Cafe Babe) at the beginning of every Java .class file ?

This magic number is used to mark the file as conforming to the class file format. I like the story behind this number.