sebastiandaschner news

monday, september 11, 2017

Hello from the city of Karlsruhe.

The last week were pretty full. Not only the normal way of full, but seriously packed. I’m currently writing my book on modern Java EE application development which understandably demands most of my current time and effort. Besides that, I’m trying to keep up on all the recent developments in the Java ecosystem.

Yes, a lot is happening right now in the world of Java.


Opening up Java EE

In August, Oracle announced to opening up Java EE by planning to move its specifications, TCKs and RIs to an open source foundation. This was, of course, very exiting news and will cause interesting news in the near future. I wrote together some thoughts on this topic in my blog.


Moving Java Forward Faster

Mark Reinhold, Oracle’s Chief Architect of the Java Platform also just recently proposed to shorten the time between Java release versions. The idea is to go for "[…​] a new feature release every six months, update releases every quarter, and a long-term support release every three years.".

I highly welcome this consideration that would lead to a faster evolving Java platform. Shorter interation cycles together with the same, backwards-compatible nature of Java enables developers to use language improvements earlier.

However, I don’t agree on the proposed naming convention, yet. It currently intends to be String version = releaseDate.format(DateTimeFormatter.ofPattern("yy.M")) — such as in 17.9 for a September 2017 version. I would suggest to continue the versions numbers as of today, such as 10, 11, 12, …​

With the way how features and bugfixes of the Java platform currently progress, it probably wouldn’t add too much value to introduce semantic versioning. Breaking versioning conventions always disrupts the involved industry — and in this case I would argue that it’s not necessarily needed.


The Road to BaselOne

As if the last days and weeks didn’t bring enough exciting work and news already — I can announce that today is the first day and stop of the Road to BaselOne. As Andrés Almiray already announced in his blog, Andrés, Ixchel Ruiz, Kirk Pepperdine and myself will go on a Java-Tour through middle Europe — Germany, northern Italy and Switzerland. The idea is to go on a road trip that ends in the city of Basel — the location of the BaselOne conference.

This evening is the first stop for the Karlsruhe JUG.

You can follow the progress tour on Twitter via @kcpeppe, @ixchelruiz, @aalmiray, or @DaschnerS. We will use the hashtag #RoadToBaselOne for this tour.

The itinerary looks like follows:

  • Sep 11th: Karlsruhe JUG

  • Sep 12th: Stuttgart JUG

  • Sep 13th: Cloud Native Night Munich

  • Sep 14th: Zürich JUG

  • Sep 15th: JUG Lugano

  • Sep 18th: JUG Milano

  • Sep 19th: JUG Torino

  • Sep 20th: Geneva JUG

  • Sep 21st: Basel JUG

So, maybe see you in one of these cities or online.


JavaOne sessions

I’m proud to announce that I will speak on the JavaOne conference again. You can find the list of my sessions here.

In Event Sourcing, Distributed Systems, and CQRS with Java EE [CON7474] I’ll present the topic of event sourcing, event-driving architectures and the CQRS principle implemented with Java. This session will show why enterprise developers should care about these buzzwords, what the shortcomings of CRUD-based applications in a distributed world are and how to tackle CQRS with Java EE.

In Motorbikes, Java, IoT, and a Hot Springs Unconference in Japan [CON7266], another, certainly fun session will be together with Java Community Manager Steve Chin about attempting to bring the Java community in Japan to a global audience. In May, Steve and myself went to the second edition of our Java motorbike tour, visiting conferences and about a dozen of Java User Groups in Japan. We furthermore organized the first version of the JOnsen unconference. We will present our impressions, including a lot of pictures and video footage.

And also I will be involved in the Community Keynote. The plot is, of course, still a secret, but keep calm and watch out for JVM agents ;-)

Custom AssertJ assertions

Now, finally, some Java content.

In a previous issue I presented AssertJ as an alternative matching library to the widely used Hamcrest matchers. For my own projects I in fact have changed to solely use AssertJ — I just find the fluid interfaces and extensibility quite appealing.

You can write custom assertions as follows.

Imagine a coffee with a strength and a drink type, such as Espresso or Latte. A custom CoffeeAssert validates coffee instances based on their custom business logic — in this case their properties.

public class CoffeeAssert extends AbstractAssert<CoffeeAssert, Coffee> {

    public CoffeeAssert(Coffee actual) {
        super(actual, CoffeeAssert.class);

    public static CoffeeAssert assertThat(Coffee actual) {
        return new CoffeeAssert(actual);

    public CoffeeAssert hasType(Coffee.Type type) {

        if (actual.getType() != type) {
            failWithMessage("Expected the coffee type to be <%s> but was <%s>",
                    type, actual.getType());

        return this;

    // hasStrength(Strength) omitted ...

    public CoffeeAssert isNotDecaf() {

        if (actual.getStrength() == Coffee.Strength.DECAF) {
            failWithMessage("Expected a coffee but got decaf!");

        return this;

Coffee instances can then simply be validated using the custom assertion. The static import of the assertThat has to refer to CoffeeAssert.

import static;

Coffee coffee = new Coffee();


The use of custom assertions can vastly improve the quality of your test code.


Thanks a lot for reading and see you next time!


Did you like the content? You can subscribe to the newsletter for free:

All opinions are my own and do not reflect those of my employer or colleagues.