The Present and Future of Java at the GeeCon Conference 2019

Each year, there's one special Java conference for me. It's GeeCon in Prague because Prague is my home city where I work and live and where I know so many great people in the Java community. This year, I had the opportunity to be a part of GeeCon again as a speaker. As is true every year, GeeCon was well organized, with a lot of interesting international and local speakers and a huge crowd of passionate attendees. All of this made the conference exceptional and worth attending.

My talk about reactive APIs in MicroProfile was scheduled for the second day. Later in this article, I'll describe what my presentation was about and show some code examples. But first, I'll write about what I experienced during GeeCon, especially on the first day when I had enough time to attend some sessions and join interesting discussions about Java between the sessions.

What Happened at GeeCon

The session about escaping the JAR hell with Jigsaw layers was very enlightening for me. The concept of using module layers to isolate classes that are part of Java modules is very interesting. Especially in the world of application servers, which isolate server's code from application code. And Nikita Lipsky realized this. He even went far enough to create a fork of Tomcat to use this concept to deploy WAR files containing Java modules. This could open the path for Java module support in application servers, which many believe is impossible to implement. If you're interested to learn more, here's the source code of the forked Tomcat: https://github.com/pjBooms/tomcat

I'm glad that I could talk to my friends at Pivotal about what they are up to and what they expect from collaboration in Jakarta EE and MicroProfile. They gave me  important feedback where the standardization effort should improve to suit them better and also to attract more like them who are interested in participating on Java standards. I also met some friends from Oracle and Red Hat. This lead to a fruitful discussion about the current state of MicroProfile and the future of Jakarta EE. These face-to-face discussions always encourage an exchange of ideas and help us find some common ground that we can pursue with our partners in the future.

On the second day, I attended a session by Martin Štefanko about a new specification in MicroProfile that addresses transactions for Microservices. For many Microservices applications, traditional distributed ACID transactions are not convenient and eventual consistency suits them better. The new MicroProfile LRA specification supports the eventually consistent SAGA pattern with a simple to use set of annotations.

My Talk about Reactive APIs

In the afternoon, it was my turn to give a presentation called Reactive Features of MicroProfile You Need to Learn. I explained why reactive programming matters, how the Java ecosystem supports it and how to simplify reactive programming for developers. One of the ways is to have a standard and simple-to-use API to write reactive code, which is familiar to any Java developer and powerful enough to cover all their needs. MicroProfile reactive operators API attempts to do this, with the API heavily inspired by the standard Java Streams API and mixing the best parts from existing reactive libraries to fill the missing gaps. MicroProfile also provides a set of APIs for messaging, which supports reactive processing out of the box and is again very straightforward and easy to use. These APIs in MicroProfile even aspire to bring unified reactive APIs to Jakarta EE and even to Java SE to make them more accessible to any Java developer. So I recommend exploring them and paying attention to how this effort evolves in the future.

To give you some taste of the APIs, I'll compare the MicroProfile API to the standard Java Stream API.

Here's an example code of a Message-Driven bean that uses Java Streams API to handle a message, process it and send it to an injected consumer:

@MessageDriven(mappedName = "topicName")
public class JavaStreamMDB implements MessageListener {

    @Inject
    Consumer payloadConsumer;
    
    public void onMessage(Message msg) {
        Collections.singleton(msg).stream()
                .filter(this::isValidMsg)
                .map(this::extractPayload)
                .peek(this::logPayload)
                .forEach(payloadConsumer);
    }
}

The above code will process one message at a time, will create a stream that contains a single item, and run the stream processing (filter, map, peek) on that single item. Finally, it will send the result to the injected consumer. Although the above code is familiar to any Java programmer, it's clear that the combination of MDBs and Java Streams is not suitable to write reactive applications. This piece of code isn't reactive and is probably too complicated in this case, because we don't need streams to process a single item. But it's a good example of what we might want to write to process a whole stream of items if it was supported by the API.

The above code can be rewritten using a very similar MicroProfile API, only this time making the code reactive and stream aware:

@Incoming("rawData")
@Outgoing("processedData")
public ProcessorBuilder<String, String> createProcessor() {
return ReactiveStreams.<String>builder()
.filter(this::isValidMsg)
.map(this::extractPayload)
.peek(this::logPayload)
.onError(this::handleError)
.onComplete(this::finish);
}

The structure of the code is similar to the first example and most of the methods have the same names and similar meaning. But there are a few notable differences:

• The method can be used in any CDI bean, not only in an MDB.
• The method is annotated with @Incoming and @Outgoing instead of MDB annotations on the class. These allow to specify the name of both the incoming and outgoing channel, not only the incoming channel as with MDB.
• The method returns ProcessorBuilder which contains instructions to execute for each item. In a simpler case when a processing pipeline isn't needed, it's also possible to use a method that just accepts an incoming item as a single parameter and returns the outgoing item, like this: public String onMessage(String data) . Such method is then called for every incoming item, similar to MDB.
• The API supports adding exception handlers so that it's possible to recover from every single failure and continue processing the rest of the stream. Java Stream API isn't so convenient and any exception during processing terminates the processing.
• The API allows running a handler on completion. This is necessary because the pipeline will be executed asynchronously unlike Java Stream API, which would block execution until processing is finished.

Here are the slides for my presentation.

You can learn more at the Reactive Operators API release page and at the Reactive Messaging release page.

Final Message from GeeCon

Being at GeeCon was a powerful experience, full of interaction with other attendees, speakers and exhibitors (yes, most of the stands had some competitions and fun stuff ☺).

You could feel the passion for Java and programming everywhere. But, coding is not everything, as Heinz Kabutz reminded at the final keynote. Even though programming is a passion for many of us, it's not a "safe" occupation. Remember that "much study wearies the body" and every programmer should take care of his/her health and body as much as possible.

Our Involvement in the Future of Java

Attending industry conferences is just one of the ways the Payara Team stays up-to-date with the latest happenings in the Java community. Payara's position as an Eclipse Foundation Solutions member,  the Project Management Committee, and Strategic Member of both the Jakarta EE Working Group and MicroProfile, ensures we evolve industry standards to meet our customer needs.

To give the reactive features from my GeeCon talk a try using the Payara Micro implementation of MicroProfile, use the MicroProfile Starter to generate a MicroProfile Maven Project with code examples: https://start.microprofile.io/.