Introduction
As you might already know, every October there is a yearly Java developer conference called Devoxx held in Antwerp, Belgium. This year, thanks to my company, I had the chance to attend it with a colleague. In this post, I will be telling, strictly from my viewpoint, about my impressions about the conference, the community, what the “hot topics” are, and the general direction into the Java world is going.
About Devoxx
Devoxx is not a “Java only” conference; there are talks, workshops about software development methodologies, other languages, general software engineering principles, and even some Frontend content. However, that is only about 10% of all the content. Mainly it is focused on Java: the Java language, as well as the whole ecosystem with frameworks, other JVM languages, JVM internals, and so on.
As an example, when one of the speakers asked for the Java Backend developers in the room to raise their hands, it was nearly everyone. Only 2-3 hands were in the air for Android developers. It is really nice to meet the Java community there as well. From my impression, people are very nice and friendly. Most importantly, they are not arrogant – but humble. It feels good to be among them. And it is even more exciting to see the Java language architects like Brian Goetz and Mark Reinhold, legends like Martin Odersky, Venkat Subramaniam and many other Java champions/significant people of the field.
Hot Topics
tl;dr: Java 9, JPMS, new Java release schedule, Project Amber, Kotlin, Spring 5, Spring Boot 2, Reactive Programming & Web, Kubernetes, microservices, functional programming (it is hot since a long time, but Kotlin amplifies it).
These are “hot topics”, according to my observation, since most talks and content were about them. So, let’s go over these topics a bit in detail:
Java 9 & JPMS (Java Platform Module System)
After getting rejected once in the public review ballot, Java 9 finally got released in September 2017.
It contains maybe one of the most significant changes since the birth of Java – the module system, a.k.a. the project Jigsaw. The project had 2 goals: strong encapsulation and reliable configuration. It can be seen as paying off all the technical debt of ~20 years of Java. That is: splitting it into logical modules, coming up with a module dependency graph, getting rid of circular dependencies, and implementing a real encapsulation for each module.
It doesn’t only modularize the core Java APIs, but also allows libraries/applications to be packaged as modules. Currently, many open source libraries/frameworks are working on their modularization and compatibility with Java 9.
There were some great talks about the module system & migration to it, by the Chief Java Architect, Mark Reinhold. These were among my favorite talks:
Some points to keep in mind before switching to modules:
- It is fair to say that module system is the biggest change in the history of Java. This makes it non-trivial to adopt, and many business applications will stay on Java 8. So, you should first decide if you need to do it in the first place.
- If you have decided to do it, wait for the (most) libraries you depend on to modularize first, to get the most benefits of JPMS.
- If you are an open source library maintainer, it is a good idea to modularize your library. This way the users of the library can fully modularize their projects as well and get all the benefits. Good thing is, you can stay compatible with older Java versions – the special “module-info.java” file will simply be ignored by previous versions (since hyphen is not a valid character in a class name).
- If you cannot modularize right now, but plans to do it in the future, at least, you can declare a stable module name in your .jar manifest file by adding an “Automatic-Module-Name” entry. This way, a stable module name will be generated for your jar, and projects that depend on your library will not end up in a jar hell.
Other than the module system, Java 9 introduces some new APIs. My favorite among them is the process API, allowing to manage processes in an OS-independent and clean way.
Another significant change is the compact strings – starting with Java 9, the String class is backed by a byte array instead of a char array. It will reduce the memory footprint of most applications, considering every char is 2 bytes (due to internal UTF-16 representation). From Java 9 and on, if every character of a string can be represented in LATIN-1 encoding, they will take 1 byte per character.
New Release Schedule
For Java developers, one of the many pain points was the release schedule. Waiting for years for small language improvements, syntactic sugars and sometimes even fixes, caused lots of complaints, and probably even pushed some people away.
Luckily, this is finally changing. Java is switching to a more frequent, fixed release schedule – to release every 6 months, every March and September. That means, Java 10 will come in March 2018, and Java 11 will be in September 2018. However, it is important to note that there will be a long-term support release once in every 3 years. Yes, even Java 9 is a non-LTS release, and the next LTS release will be Java 11 (Java 8 is considered as an LTS release). So, for critical applications, it is probably better to check every new Java version for compatibility, but only use LTS versions for production.
A great talk by the architects about the new release schedule can be found at the link below:
Project Amber
This is about “right-sizing” the language ceremony, by adding some productivity-oriented language features for tedious, repetitive operations. It consists of:
- Local Variable Type Inference: The var keyword that has been used in many languages, like C#, Scala, Kotlin, since the type can be inferred from the right side of the assignment. Basically, this (using the same example on Goetz’ talk):
URL url = new URL("https://www.mobilabsolutions.com");
URLConnection conn = url.openConnection();
Reader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
becomes
var url = new URL("https://www.mobilabsolutions.com");
var conn = url.openConnection();
var reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
- Enhanced Enums: Adding generics support to enums.
- Lambda Leftovers: Being able to use _ for the unused lambda parameters.
- Data Classes: This should not be confused with the value types, which is a topic of another project, the project Valhalla. Data classes are simply about having simple classes that only contain data, without any logic. So, the equals/hashCode/toString methods will be automatically generated for them. Even more importantly, they can be deconstructed. This would allow them to be used in the next important feature: pattern matching.
- Pattern Matching: Neither data classes nor pattern matching is new to the developers that work on modern languages, such as Scala or Kotlin. However, it is still good to finally have them in Java. Pattern matching is basically a “switch on steroids” that allows much more flexible matching such as matching by type, value, properties (of data classes). In addition, it will be an expression and not a statement, a switch had to be in the first place.
A great talk about the project:
Kotlin
And here we come to my favorite topic: the new kid in the block, the new, the shiny JVM language by JetBrains. Actually, I am not sure if calling Kotlin “new” is fair – It first appeared in 2011, 6 years ago. However, throughout the years, it drew lots of attention to itself, and in the last 1-2 years or so, it is one of the hottest stuff in the Java world – both on Android and the backend sides.
Kotlin actually looks pretty much like Scala, and feature-wise, it can even be seen as a subset of it. However their goals are different, and in my opinion, Kotlin’s are more “to-the-point”: Not to branch away from the Java community and frameworks, but to embrace them. To focus more on business needs, rather than the academic purposes. To provide a great tooling support, and a soft transition/migration possibility. It tries to solve the pain points of Java, while not shifting away from its fundamentals, and does an amazing job in it.
After it being announced as an officially supported language for Android development by Google, the Spring Framework (starting with version 5) officially added first-class support for it, along with Groovy, and of course, keeping Java. And, they even added some Kotlin extensions for bean registration and routing configuration, by leveraging Kotlin’s functional DSL support.
We actually started to use/migrate to Kotlin on some of our backend projects, and so far, we are already in love with it.
But I should note that Kotlin is way beyond being only a JVM language. Actually, it can compile to Javascript, to native code (in progress), it is also working on adding very interesting features such as coroutines.
Some of the good talks about Kotlin, from the Devoxx Belgium:
- Kotlin for Java Programmers by Venkat Subramaniam
- Building Cloud Native Progressive Web Apps by Matt Raible and Josh Long
Spring Framework 5 & Spring Boot 2.0
Spring 5 focuses mostly on reactive programming, especially on web apps. It uses Reactor to support the Reactive Streams API, and introduces Spring WebFlux – an alternative to Spring MVC, to build non-blocking, reactive web apps. It can leverage the non-blocking nature of Netty and Undertow to achieve its goals (it also works on Tomcat and Jetty). Actually, Spring Boot 2 uses and requires Spring Framework 5, and for WebFlux, it uses Netty as the default network application framework.
Spring Boot also supports reactive access to the data layer, thanks to the added support for reactive accessors on spring-data project (currently only for MongoDB, Cassandra, and Redis). This allows fully reactive programming, from the data access layer to the web endpoint.
Kubernetes / Microservices
Microservices in containers has been the trend for the last couple of years on the backend world, and Kubernetes is the most popular container orchestration system. There were some interesting talks about using Spring Boot/JHipster to build microservices and deploying them on Kubernetes clusters, and about troubleshooting/debugging Kubernetes deployments.
Functional Programming
Especially since Scala has proven that functional paradigm can happily coexist with the good old object-oriented paradigm, it gained more and more attention over the years. With Java 8, lambdas and stream API have been introduced to the language, and even brought more attention to the topic. And now, with the rise of Kotlin and the reactive web programming, it is even stronger than before among the Java Community. Two of my favorite talks were in that topic:
Conclusion
For the ones wondering, no, Java is not dying. In fact, many interesting developments and powerful technologies are coming up to the Java world on the Server Side. Attending Devoxx is an unforgettable experience for a Java developer, to catch the latest developments/trends of the Java world.
Special thanks to my company MobiLab Solutions for sending us there, to experience it first-hand.
Utku is a software developer at MobiLab’s Berlin office. He is working on Server-Side development, mostly with Java & Kotlin.
