JCON EUROPE 2023

Relational databases and the JPA (Jakarta Persistence API) standard were designed for monolithic systems and have been a great success story. However, there are also various challenges, but after so much time these are simply part of the process.

Cloud, containers, microservices, and serverless computing are currently changing the entire software industry. With NoSQL, serious alternatives came up for the first time, but just storing data in cloud-native environments becomes more and more challenging and expensive.

The upcoming Eclipse Persistence API specification is built to fix this. It's built for the cloud and enables to store Java objects seamlessly into cloud-native data storage, enables high-performance in-memory data processing, and saves up to 90% on cloud storage costs. It fits seamlessly into Core Java concepts and is way easier to use.

The amount of data collected by applications nowadays is growing rapidly. Many of them need to support both relational SQL and non-relational NoSQL databases. Jakarta Data provides an API to allow easy data access. Developers can split the persistence mechanism and the model using common features like the Repository pattern and seamlessly switch between SQL and NoSQL databases or even use both in the same application.

First we'll compare popular Java data access frameworks for SQL/JPA and NoSQL databases. We are going to look at Jakarta NoSQL/JNOSQL, Spring Data, Micronaut Data, Quarkus/Panache or DeltaSpike Data. What do they have in common? How do they compare, what are the strengths, weaknesses, differences and similarities? We'll show each of them with a selection of different NoSQL or SQL databases to learn how they work and what concepts like CRUD operations, the Repository pattern, pagination or sorting they support.
Followed by an overview of Jakarta Data and how it can help migrate your data applications to a vendor-neutral future, becoming greater than the sum of all existing solutions.

Viele neue Anwendungen werden so geschrieben, dass sie in der Cloud betrieben werden können. Beim Design und der Implementierung wird darauf geachtet Vorteile einer Kubernetes Umgebung zu nutzen und die Anwendung ideal in einem Container zu betreiben. Was aber macht man mit einer - noch nicht so - alten Anwendung, die in einer Application-Server Umgebung läuft und fit gemacht werden soll für die Zukunft?

Vor dieser Aufgabe standen wir bei der Migration einer Jakarta EE Anwendung. Die vorhandene Anwendung wurde als EAR in einem Application-Server deployt. Die Migration sollte ohne die Nutzung eines Application-Servers erfolgen. Gleichzeitig sollten die bei einer cloud nativen Anwendung üblichen Techniken wir Health-Checks, Metriken, strukturiertes Logging verwendet werden.

Als gangbarer Weg erwies sich die Nutzung von Quarkus als "Laufzeitumgebung" für die Anwendung. Durch die Nutzung von Jakarta EE Spezifikationen wurde eine umfangreiche Umprogrammierung vermieden. Die neuen cloud spezifischen Techniken konnte leicht integriert werden.

In diesem Vortrag wird die Migration der Anwendung von Jakarta EE zu Quarkus beschrieben. Dabei gab es verschiedene Herausforderungen zu meistern. Was konnte bei der Migration übernommen werden und wo mussten (Design-) Anpassungen vorgenommen werden?

Bei der Anwendung handelt es sich nicht um eine klassische Enterprise Anwendung. Somit werden Themen wie Transaktionen und die Migration von Web-Oberflächen (JSP, JSF, ...) nicht behandelt.

Do you still remember EJBs and application servers? Then you are a "serverless expert." :-) In this session, I will explain the serverless principles ...with 10+ years old code, application servers, EJBs, and Java EE APIs. I will discuss possible J2EE application migrations to full stack "low code" Java serverless architectures. We will entirely focus on business logic, consider CO2 reduction, costs, and energy efficiency, use standards and minimize external dependencies.

Live coding, live deployments, and live interactions with the audience are included.

Hibernate is the de facto standard persistence framework for traditional Java database applications. Now, Eclipse MicroStream was built to be the Java persistence for containerized microservices and serverless functions. Eclipse MicroStream follows the system prevalence architectural pattern. The engine enables seamlessly storing any Java objects of any size and complexity transaction-save into cloud-native blob stores such as AWS S3 or any other binary storage. ACID transactions are journaled and deltas of the system state are regularly saved to disk. To reduce startup time and run also with a small RAM capacity of under 1 GB, MicroStream provides lazy loading. With Java Streams API, queries are executed in memory in microseconds - way faster than comparable JPA queries. Implementing is simple. There are no requirements for the entity classes, no annotations, interfaces, or superclasses, just POJOs. Additionally, expensive mappings or any data conversions are eliminated. The core benefits are extremely high performance, simple implementation, running trouble-free with stateless microservices, and reduced cloud storage costs.

You want a service that runs immediately, is written in Kotlin or Java, and that can serve as a backend for your website. You want it to be serverless, as the numbers of users you have varies significantly. Last, but not least, you want a comfortable developer experience.

Sounds unrealistic? I’ve done it, and I’m happy!

My path through this scenario has been paved with Quarkus. Let’s see how you can set yourself up for success with Quarkus Native building and running in the cloud. I’ll use Google Cloud in this example, but it’ll all apply to other clouds as well.

During the talk, we’ll go from scratch to production. That means, all the way from downloading Quarkus until we are live.

We’ll focus quite a bit on the build process, and how to fine-tune the Dockerfile, as well as discuss the trade-offs you do when using native builds.

Helidon Níma has become the world’s first web framework which is by design based on Virtual threads – one of the major game changer in the industry. Virtual Threads, first in research Project Loom and now as a preview feature in JDK19+, dramatically change the resource usage in the JVM, allowing achieving performance comparing to reactive engines, but with fully blocking paradigm. In this talk I am going to tell you the story of Helidon Níma – what were the problems and what were the solutions, what tasks it is designed to work on, and why it has changed the world of web frameworks.

As many enterprise applications have been built using Java EE, migrating these applications to JakartaEE 10 is a key concern for developers. JakartaEE 10 is the latest version of the enterprise Java standard, and it provides a platform for building portable, cloud-native applications.

In this talk, we will explore the challenges and opportunities of migrating from Java EE to JakartaEE 10. We will begin by discussing the differences between Java EE and JakartaEE, and how the migration process differs from previous upgrades. We will then explore the steps involved in migrating an application, such as identifying the modules that need to be updated, testing the application, and deploying it to a JakartaEE 10 runtime.

One of the key challenges in migrating from Java EE to JakartaEE 10 is dealing with the removal of some of the legacy technologies that were present in earlier versions of Java EE. We will discuss strategies for dealing with this, such as using alternative technologies or refactoring the code to remove dependencies on these legacy technologies.

Throughout the talk, we will provide practical tips and best practices for migrating from Java EE to JakartaEE 10, based on our own experiences and those of the broader community. By the end of the talk, developers will have a better understanding of the challenges and opportunities of migrating to JakartaEE 10, and will be equipped with the knowledge and tools they need to make a successful transition.

Java has been leading for more than 20 years. However, Java is known as complicated, heavy-weight, slow, and for its slow startup time and high RAM consumption. Now, the cloud age has begun and the cloud changes everything. Is Java still suited for the cloud? Are traditional databases still suited for the cloud or is NoSQL the way to go? Can in-memory computing speed up my system and how does Java support it? Is serverless really interesting for Java developers and how do Java and serverless fit together?

No worries, the holy grail was already found. A completely new Java stack was created to build real cloud-native apps with Java. Native images with Java, millisecond startup-time, in-memory data processing, up to 1000x faster database queries, highly cost-efficient serverless infrastructure, everything built with pure Java. That's not a vision, it's reality. In this session, you will learn how to build ultra-fast cloud-native apps and microservices with core Java and modern Java micro-frameworks only.

For years, we’ve been told that Java suffers from cold starts in AWS Lambda and Serverless in general. Believe it not. Java is extremely fast to start, the simplest Java program starts in milliseconds. It’s the Java frameworks and libraries that slow things down in general. But not all of them…

In this session, I want to show you the truth about Serverless Java and cold starts, what’s slow, what’s fast and why it matters. We’ll go through what a cold start is, how cold starts in AWS Lambda impact your application responsiveness and cloud costs, and what are the options to optimize both. We’ll explore and compare Quarkus and Piranha Cloud, the most modern and fastest Jakarta EE frameworks. We’ll test the limits of what they are capable of, how fast they start and whether we even need to think about any optimizations. Then I’ll explain what optimizations may help if you need to go further, like tuning the JVM, using a custom JVM runtime or building a OS-native binary with GraalVM. However, there are also a few limitations and cost implications of these optimizations, which we'll also explain.

I’ll show and tell, with very few slides. You’ll see live for yourselves how Java AWS Lambda functions built with Jakarta EE can start fast and decrease the cold starts to the absolute minimum which you can barely notice.