My summary of jPrime 2022

The container technology has old roots indeed.

Containers provide lots of "magic" that other technologies don’t:

Granted, containers add some complexity, but containers are not to blame. They empower users so that we can design more complex architectures.

Here are some capabilities offered by containers:

Let’s focus on the testing part. The closer the test to the production environment, the more reliable it is. Containers can help bridge several gaps:

Testcontainers is a project introduced in 2015. It’s an Open-Source framework that allows developers to bridge the gap between the development and the production environments.

Testcontainers also allows for the most "integrated" form of testing, end-to-end browser testing:

Here’s a sample of setting up the PostgreSQL database in a container via Testcontainers.

MicroShed testing integrates with the Jakarta EE ecosystem to make use of Testcontainers. It offers several implementations:

The rest of the presentation was code and live demo

The speaker introduces the concepts of Docker and Docker images, highlighting the sizing part.

A Docker image is an archive - a collection of bytes - at its foundation. However, images are made up of layers ordered in a parent-child relationship. Both images and layers are stored in registries.

Different topologies are possible around a registry and a host: trusted registries, proxies, mirrors, PaaS registries, etc.

Pulling an image is not free. Depending on the registry, e.g., the Cloud provider can bill you. For example, Docker has enforced limited pull rates. Beyond these rates, you need to pay. For this reason, smaller images reduce costs.

In this regard, the choice of the base image is essential. Reminder: a base image starts FROM scratch.

Several approaches can keep the image small:

For Java applications, it translates into the following:

Alpine Linux is a lightweight Linux distro based on musl libc and busybox. The package is less than 3 MB "on the wire" - 10 times smaller than Ubuntu! With Alpine, one can create a container image with JDK 17 that weighs less than 100 MB on disk. It saves a lot of pull time and reduces associated costs.

Fundamental principles of musl libc:

Note that libc has several implementations beyond musl: uClibc, dictlibc, glibc, etc. We can compare them across many dimensions! All in all, the main pain point of musl is legacy code-friendly headers. Additionally, DNS resolution works differently.

The other component of Alpine is busybox: it’s a single executable file that contains many Unix utilities. For this reason, its size is small.

Other characteristics of Alpine Linux is that it comes with its dedicated package manager - apk and doesn’t offer a GUI. All in all, Alpine is perfect for containers.

Although the differences between musl and glibc are small, they exist. JDK providers wanted to close this gap. Project Portalla, aka JEP 386, aims to port Alpine Linux to x64 and AArch64 architectures. Portalla is facing a couple of issues, but developers are working on them.

The testing pyramid strategy consists of several layers.

At the unit level, you don’t depend on anything. If your test fails, you know it’s a mistake in your code. We want to bring integration tests to the same level of confidence.

Imagine a test that inserts an entity into the database and checks that the latter contains a single record. If we repeat the test with the @RepeatedTest(2) annotation, we can show that the test is not idempotent. Hence, it’s not as safe as a unit test.

To solve the problem, we can use @DirtiesContext. The annotation informs the Spring framework that executing a test has "dirtied" the context. After execution, Spring creates a new context from scratch. The cost is additional time as Spring needs to initialize the context.

An alternative is to annotate the test with @Transactional. At the end of each execution, Spring rolls back the transaction. Along with @Transactional, Spring offers @BeforeTransaction, @AfterTransaction, @Commit, and @Rollback.

Another alternative is to configure a @TestExecutionListener. With it, you can directly hack into the test lifecycle. By default, registering a new listener will replace all default listeners, including the dependency injection listener. Either you need to reintroduce them manually or configure the listener to merge the new one with the defaults.

Applications generally need to run in different contexts. For example, a developer wants to run the application locally using the H2 database, while in production, we use MySQL. @Profile is your friend in this case: one can associate beans with a specific profile. For example, you can set the H2 database in the dev profile and the MySQL to the prod profiles. At runtime, you configure which profiles are active: Spring will create beans that match the active profiles only.

To test the HTTP layer, one can inject a MockMvc instance in a test via the @AutoConfigureMockMvc annotation.

In software, we use the word "event," but different people may have a different meanings for this word. Let’s dive deeper.

Imagine a door with ID 28 and the color yellow; then it becomes red but keeps the same ID. If you only know the current state of an object, you cannot reason about the previous state. You can if you store the changes, not the state.

The definition of an event is a notification that something has happened. Because an event has happened - notice the past tense; an event is naturally immutable.

Event storming is a business process discovery and design technique. The idea is to build a shared understanding of the system between the business and developers as well as across the whole organization. Event storming sessions aim to list all possible events that can happen within the scope of a system.

Event modeling is a blueprint for a solution. Some think that storming and modeling are the same, but it’s not the talk’s goal to discuss it. Event modeling puts what a system does on a timeline with no branching. As an added benefit, it allows to uncover events that traditional specification writing wouldn’t have.

Now, what is event-driven? Two concepts are at the foundation of event-driven: producers emit events; consumers are interested in specific events. A router is a mediator between producers and consumers, which knows how to route messages from the former to the latter.

Yet, in the end, event-driven is a buzzword! It works great for product pitches, but it’s not a technically accurate term. It’s a false claim: if an event is a notification, then it doesn’t drive anything. The driving factor is a decision, either made by users or by algorithms.

Note that event-driven is also polysemy. For a more detailed explanation, watch The many meanings of event-Driven architecture.

More definitions follow. An event notification gives a notice via an event. There’s no response, and it doesn’t contain much data. If you want to know more, you need to go back to the origin system.

Event-carried state transfer introduces the plight of which data source is the source of truth, the producer or the consumer? With event streaming, the source of truth is not on the consumer side but in an in-between mediator. The mediator provides both message persistence and routing. Kafka is such a mediator.

Why does the producer need data storage if we have mediator storage? We can store everything in the mediator. Now, the mediator is the single source of truth: the mediator has become an event store.

Characteristics of an event store are:

To label oneself as event-driven, we still lack some things. A command, e.g., "Joe ordered to paint door 28 in red", is not an event. Likewise, a request for information is a query, not an event. In the latter case, the critical bit is the data contained in the response. Hence, messages have different types; an event is a specific kind of message. When a message router is available, it’s convenient to use it to route events and other messages, such as commands and queries. Oh, we just have introduced CQRS.

Greg Young introduced CQRS to separate between reads and writes. At the time, it was about having different objects, one dedicated for each operation. Nowadays, it’s about separate models, not objects. In CQRS, events are typically used to sync between the read and the write models.

Milen finishes the talk by talking about his company’s products:

The main question is how to get the JDK: on a vendor website or via a proprietary vendor API?

The situation is complex:

It’s not an easy choice!

It would be great to have one unified API to unite them all: Disco API to the rescue! The API collects a lot of information: distro, version, platform, OS, architecture, archive types, release status, term of support, package types, etc.

The API offers an HTTP URL to call but no packages. You can find the API at https://api.foojay.io/. It also provides an OpenAPI endpoint, so you can play with the API in the browser.

The API is opinionated: it doesn’t use the vendor’s name, e.g., Azul, but the distribution’s name, e.g., Zulu.

The speaker goes on to describe the API in detail

The project is available on GitHub. It also offers plugins:

One can also install the related CLI, discocli, that queries the API.

Another tool is JDKMon to detect JDKs installed:

Finally, note that the v2 of setup-java GitHub Action limits the possible JDK distributions to four options. If you need to use one that is not listed, use foojayio/setup-java instead to configure any distribution.

I’ve already written a full-fledged blog post about Evolving your APIs. Soon, the recording of the talk will be available.

jPrime is a great community-led conference. After two years of Covid, they were able to attract around 1k attendees and local and international speakers. Icing on the cake, all talks are in English!

Don’t miss the next edition, May 30-31^th 2023!