Back from Oracle Code One 2019

From September 15 to 19, I had the chance to participate in the event Oracle Code One San Francisco as a speaker. Here is my feedback.

What is Oracle Code One?

Oracle Code One San Francisco is one of the leading annual international meeting for developers. It is organized in parallel to another major event, focused on Oracle portfolio, called Oracle Open World.
Oracle Code One succeeded Java One (born 1996) in 2018. By changing its name, it aims at being more generalist than its predecessor. However Java remains one of the main topic with  GraalVM, Jakarta EE, MicroProfile, Quarkus …

A bit of context

The event takes place in the heart of San Francisco at Moscone Center. The organization is impressive and does not tolerate any flaws. There are thousands of participants and everything is done to facilitate traffic flow under the best conditions.

There are dozens of conferences in parallel and everything is well established:

• A dedicated technical team in each room to manage video and sound
• Sophisticated equipment allowing, for example, the use of several workstations during the talk

The previous weeks, several meetings were scheduled for the speakers to avoid last-minute unpleasant surprises, backed by a Speaker Resource Center portal to check that everything was on track.

In addition to conferences and keynotes, evening events are also organized, including Oracle CloudFest on Wednesday. In this case, it was a concert with John Mayer and Flo Rida in a brand new hall designed for basketball (NBA version of course): the Chase Center. A typical US atmosphere!

I had also the chance to be invited to several “private” technical events, thanks to my Tomitribe friends, that allowed me to meet the best of Java speakers and influencers:

• Oracle Dev Appreciation Event
• Cloud-native Java Networking
• Java Influencing Gathering in Google’s offices

Other meetings were held, such as those of the Java Champions and the Java Community Process.

Beyond the conferences, Oracle Code One is also an opportunity to meet, exchange and network.

Let’s now move on to more technical topics.

Java in the cloud: a good citizen at last?

Java’s number one challenge is to successfully transform it for the cloud and in particular with infrastructures based on Kubernetes and Docker. Hence, the following topics were heavily discussed:

• Best practices to reduce the size of Docker images
• How to improve applications startup time
• How to reduce the applications memory footprint

Indeed, the Java SE platform is 25 years old and Java EE (now Jakarta EE) is 20 years old. A time when production was run on dedicated on-premise servers. As a result, an enterprise Java application is optimized for long-term run. It starts off rather slowly and then increases its performance to reach an optimum after a ramp up period. Similarly, it does not seek to reduce its memory footprint during operation but rather to improve its throughput.
In a cloud environment, on the other hand, you need a quick start and a small memory footprint. Hence, Java must become frugal to be up to the competition such as Go, Node.js, Python …

Several solutions are available:

• Alternative JVMs to the HotSpot such as OpenJ9 which tends to reduce startup times (15% on average according to my tests thanks to the share classes mechanism) and memory footprint (30% on average according to my tests). OpenJ9 is an original IBM technology that has become an Open Source project hosted by the Eclipse Foundation
• Modern lightweight, modular application servers and frameworks such as Oracle Helidon, Red Hat Quarkus, IBM OpenLiberty, TomEE, KumuluzEE, Payara Micro …
• The JDK modularity which allows to produce JRE images reduced to the strictly necessary application and JRE modules

Quarkus: evolution or revolution?

Red Hat proposes a disruptive approach with Quarkus which, according to its slogan, aims at making Java “Supersonic Subatomic”. I like the slogan and I like the T-shirt even more!

Quarkus supports traditional programming models such as Java/Jakarta EE and MicroProfile (and even Spring since version 0.20.0) while offering significantly improved performance in startup time and memory footprint (the two historical weaknesses of Java).

The “magic” of Quarkus lies in the fact that you develop with traditional tools (IDE, simple editor, Maven Graddle) and you can execute in two modes:

1. The traditional JVM mode with significant performance enhancements
2. The new binary mode (with an executable based on GraalVM): with really impressive startup time and memory footprint

To learn more about performance, I recommend reading this article Quarkus Runtime Performance. This article is very interesting because it explains the differences and under what conditions the JVM remains a good option. It’s not just black and white!

To achieve this level of performance, Quarkus is based on a simple principle: anticipate things as much as possible at build time. Everything that is normally executed at run time, when the application is launched, is made during the build phase. For instance, identify annotated classes and instrument them so that they implement the expected functionalities: JPA entities, CDI beans …

However, there are counterparts:

• The dynamic aspect of Java at the runtime is lost: introspection, instrumentation, proxy creation… Everything is done beforehand in the build phase. Even if Quarkus is able to deduce a lot of things, sometimes you have to help him with some specific annotations
• For a framework or library to be supported, it is necessary to develop an extension that will perform this preparation work. I must humbly admit that all this remains a little mysterious for the moment, but I do not despair to understand and one day develop an extension

I’m not an analyst but I do think that Quarkus is a “game changer” that opens an interesting way for the future of Java. For the sake of equity, we can also mention Micronaut, which proposes a similar approach.

GraalVM: back to binary!

To operate in binary mode, Quarkus relies on GraalVM. This is an Oracle Labs project that aims to be “a high performance polyglot VM”. It allows for example to mix code from different programming languages running in the same VM. For instance: R to perform some data-science computing mixed with Java MicroProfile to expose REST interfaces.

GraalVM also allows to run Java in binary mode thanks to a specific VM named SubstrateVM which manages the runtime aspects: threads, memory etc … The fun thing is that I started my career by developing binary executables written in C/UNIX, I may end it by developing binaries written in Java.

Beyond Jakarta EE 8

Jakarta EE 8 was released on September 10, just before the Oracle Code One. This milestone officially marks the end of the transfer from Oracle to the Eclipse Foundation. The main characteristics of Jakarta EE 8 are:

• Same technical content as Java EE 8 (no new feature)
• New artifacts coordinates
• New specification process aligned with the Open Source context
• The Technology Compatibility Kit has been open sourced: previously it was closed and subject to specific fees. It is now fully open with a principle of self-certification,
• The notion of reference implementation is replaced by that of compatible implementations

As of this date (Oct. 9, 2019) there are 4 compatible products: Payara, IBM Open Liberty, GlasFish, Red Hat WildFly.

Two years after its announcement, Jakarta EE is ready to move forward. It is now at  at a crossroads, facing its destiny. The challenges of its success are:

• The renaming modalities of javax.* packages to jakarta.* (Oracle’s legal obligation): big bang or incremental, the issue is still under discussion
• The relationship with MicroProfile which seems not as simple as expected (see below)
• The effective contribution of the community

MicroProfile relationship with Jakarta EE

Now that Jakarta EE is ready to move forward, the question arises of the relationship with MicroProfile. As a reminder, MicroProfile was launched in 2016 to modernize Enterprise Java in response to Java EE lack of progress.

By nature, MicroProfile and Jakarta EE are closely linked:

• Both are Open Source and hosted by the Eclipse Foundation
• They share more or less same contributors
• MicroProfiles relies on some Jakarta EE specifications

In 3 years, MicroProfile has acquired its own identity and notoriety. It has moved beyond the stage of a simple “incubator” project. A reflection is underway within the communities to determine how to preserve this identity while converging with Jakarta EE. I’m not doing to dive into the details of the discussion, here is what I learned from it:

• The two projects must continue to evolve in parallel and in complement with different life cycles and focus
• The focus of MicroProfile is innovation
• The focus of Jakarta EE is stability
• Some MicroProfile specifications (such as config) are intended to join Jakarta EE as long as they are sufficiently natural and stable. How this could happen is subject to discussion

My experience as a speaker

I was invited as a speaker. I’ve submitted a talk (with Sébastien Blanc) in response to the Call For Paper without really believing in a positive answer. The paradox is that I learned the good news while on vacation on the island of Java … Nice symbol!

When I participated in Java One in 2016, I could not have imagined being a speaker at the same place 3 years later! It was an honor and a great challenge.

Our talk was entitled Java server-side: 20 years old and still innovative. It was made of a few slides (reminding the evolution of Java EE and the rise of cloud-native applications, available from the previous link) and  a demo, inspired from a real use-case, showing how to make the most of  Java to develop cloud-native applications. We’ve tried to be as exhaustive as possible by using :

• Several JVM: HotSpot, OpenJ9, GraalVM
• Several application servers and libraries: TomEE, Payara Micro, KumuluzEE and Quarkus

Conclusion

Beyond the technical aspects, which were very interesting,  I’ve really appreciated the friendship within the Java community. I was able to approach the “best of the best” in all simplicity.

To conclude, I would like to thank:

• My company Worldline which allowed me to live this amazing  experience
• My friends from Tomitribe (in particular Amélia Eiras, David Blevins, Jean-Louis Monteiro and Cesar Hernandez) who were kind enough to welcome me and open all the doors to meet the influential people of the Java ecosystem
• My co-speaker Sébastien Blanc who accompanied me enthusiastically in this adventure