Devoxx 2018 Recap: The State of Java and its Ecosystem

This article reflects my subjective learning from the Devoxx Belgium 2018 conference.

I visited Devoxx, a conference about the Java programming language and its ecosystem, for the first time in 2017. That was the year when Oracle announced Java’s new semi-annual release model. Java 9 and its module system was also brand new. Spring released Reactor, which provided an alternative application model to the default MVC style.

Everybody was curious how these new developments would work out in practice. So this year, I was quite excited to see how the Java community has adopted these "technological outbursts".

Java 8 rules

I got the impression that a large majority of the community is still running on Java 8. It seems that everybody wants somebody else to take the first step into Java 9 or 11. This doesn't come as a surprise since the Java devs, in general, are more cautious towards new technology than, for example, the JavaScript community.

Mark Reinhold, the Java platform’s chief architect, said that Java's purpose is not to be among the early adopters of new features. The Java team tends to watch other languages, analyse the success criteria of new features and then assimilate these features as if they always belonged to Java in the first place.

The talks (Java Today and Tomorrow, Amber & ValhallaLoom, Panama, ) covering the current development in Java just confirmed that attitude even more.

Spring: Thriving as ever

As long as I can remember, Spring has always tried to support the latest Java versions. So it came as quite a surprise when Jürgen Höller actually discouraged the use of Java 11. He pointed out that this was not because of Spring itself. Instead, the problems lie more in the libraries you might use in addition to Spring. Still, he highly recommended writing in Java 8 but using Java 11 as runtime since the newer runtime is far better.

Another interesting finding was how you can combine the Java 9 module system with Spring. According to Oliver Gierke, this doesn't fit very well because Oracle primarily targeted its own JDK when they came up with their module system.

That's why there exists, exclusively for Spring, an alternative called Moduliths. Using this library can prevent wild injections of Spring Beans between packages that ought to represent logical modules. You can do this by annotating these packages as @Moduliths.

Application Architectures

Oliver's talk about Moduliths was quite notable from another perspective. He encouraged us to stick to monolithic applications instead of using a microservices architecture. Two other talks, namely (Majestic Modules, System of Systems), centered around this topic. It seems that more and more people are aware that microservices are not the silver bullet or the glorious saviour for the challenges software architects face.

We can also use monolithic systems to build applications with well defined and isolated modules. By doing that, we don't have the additional infrastructure overhead required to manage multiple services. Furthermore, monolithic services are far superior when the time comes to restructure the modules, like when moving parts from one module to another.

Future developments

Concurrency seems to be the new hot topic. Unlike many years before, it isn't about multi-threading programming. The magic word is “asynchronous programming” which is already quite common in Node.js. There were some quite-interesting talks centering around this topic, including Reactive Programming, the classic Functional Oriented Programming, Kotlin's Coroutines or the quite promising developments in Java with Continuations and Fibers.

Asynchronous code lets us label certain parts of the code as "waiting" so the Engine can automatically free up sparse and precious threads for other tasks. An example might be a web server with a limited set of threads available that has to deal with lots of parallel requests.

So the solution to concurrency is not to make the developer manage the threads, but to give the Runtime enough information to fully automate these complicated tasks.


Overall, I noted a slow adoption rate for Java versions above 8. Spring remains a solid and stable framework that keeps itself open for innovation and tries out new features without neglecting its stability and maturity.

Besides the developments in Java and Spring, Devoxx also provided a variety of talks that covered virtually every current "hot topic" (be aware, buzzwords ahead): Kotlin, GraalVM, Reactive Programming, Fibers & Continuations, Blockchain, and FP vs OOP. Talks also covered non-technical stuff such as self-improvement and attitude.

I think Devoxx can become even better by providing more opportunities for participants to connect. While Devoxx’s organisers included social events like a movie in the evening, other conferences offer more. An example might be "Open Space", a session where participants discuss topics they choose on their own.

And let’s face it, Antwerpen is not that easy to reach!

Leave a Reply