DEV Community: Renato Fialho

Java 19 and the new Virtual Threads

Renato Fialho — Tue, 27 Sep 2022 13:59:21 +0000

This post can be read here as well.

What?

Java 19 is coming, and with this new version of Java, it brings an amazing new feature, virtual threads.

This update comes to reduce the effort of writing, maintaining, and observing high-throughput, concurrent applications.

This is part of the Project Loom, a project that aims to bring a new concurrency model to java, but preserving the same simple abstraction to the developers.

Don't worry, you will still be able to use the platform threads.

How?

Currently, those implementations are on preview mode, so you must provide the --enable-preview flag to the JVM.

If you are an IntelliJ user, you can tell IntelliJ to use this flag by going into the Open Module Settings -> Project -> Language Level and choose the Java 19 (Preview).

    // Declare a runnable that will print the information about the current thread
    Runnable printThread = () -> System.out.println(Thread.currentThread());

    // Declare a virtual thread
    var virtualThread = Thread.ofVirtual()
        .start(printThread);

    // Declare a platform thread
    var platformThread = Thread.ofPlatform()
        .start(printThread);

The output will be:

    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1
    Thread[#24,Thread-0,5,main]

Now you see that we have a virtual thread executing on a worker thread of the Fork-Join pool, and another platform thread running on the main process.

Seamless integration between platform and virtual threads

Synchronized blocks will work transparent in between virtual and platform threads, as it is shown in this example.

class VirtualThreads {

    public static void main(String[] args) {
        var c = new VirtualThreads();
        c.start();
    }

    public void start() {
        var virtualThread = Thread.ofVirtual();
        var platformThread = Thread.ofPlatform();

        virtualThread.start(() -> {
            System.out.println(Thread.currentThread() + " running command A");
            synchronized(this) {
                try {
                    this.wait();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
            System.out.println(Thread.currentThread() + " running command C");
        });

        platformThread.start(() -> {
            System.out.println(Thread.currentThread() + " running command B");
            synchronized(this) {
                this.notifyAll();
            }
        });
    }
}

The output will be:

    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1 running command A
    Thread[#24,Thread-0,5,main] running command B
    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1 running command C

Loom and Java in general are prominently devoted to building web applications. Obviously, Java is used in many other areas, and the ideas introduced by Loom may well be useful in these applications.

It’s easy to see how massively increasing thread efficiency, and dramatically reducing the resource requirements for handling multiple competing needs, will result in greater throughput for servers. Better handling of requests and responses is a bottom-line win for a whole universe of existing and to-be-built Java applications.

Reference

Learn SOLID design principles using Java

Renato Fialho — Mon, 26 Sep 2022 15:40:04 +0000

This post can be seen here as well.

The main idea from this article is to show the SOLID design principles and provide examples of implementations of those principles using Java as the main language.

What is SOLID?

S.O.L.I.D stands for:

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Design principles in general helps us to write better software. And also improves the developer experience of the developers that share the same codebase with you.

Single Responsibility Principle

A class should have only one responsibility.

It helps into onboarding new members into the code, as well to test, maintain and grow our codebase.

Example

Imagine that you have a UserService that is like this:

class UserService {

    public void createUser() {
        // Create our user here
    }

    public User findById(UUID id) {
        // Return our user
    }

    private void sendAppNotification() {
        // Send an app notification
    }

    private void sendEmail() {
        // Send an email
    }
}

What happens if the requirements of this class change? What if now we must send a tex now we have to send an App Notification via push or SMS?

Then, we must separate the concerns and responsability by creating a NotificationService that will handle all of our communications.

class UserService {

    private final NotificationService notificationService;

    public void createUser() {
        // Create our user here
    }

    public User findById(UUID id) {
        // Return our user
    }
}

class NotificationService {
    public void sendSms() {
        // Send SMS
    }

    public void sendPushNotification() {
        // Send push
    }

    public void sendEmail() {
        // Send email
    }
}

Even though it can have better approaches here, the idea is to separate concerns, the other solutions to solve this kind of problem is a different topic.

Open Closed Principle

Software entities (classes, modules, functions, etc.) should be opened to extension but closed to modification.

Example

Think that we have an CoffeeApp class

public class CoffeeApp {
    public void brewSimpleCoffee() {
        // Put water
        // Put coffee powder
    }

    public void brewPremiumCoffee() {
        // Get the bean
        // Grind the bean
        // Put water
    }
}

Imagine that everytime our system needs to support a new type of coffee, we must change the Machine in order to add a new type.

Lets use of simple abstraction and polymorphism to improve this

public class CoffeeApp {
    public static void greet(CoffeeMachine coffeeMachine) {
        coffeeMachine.brewCoffee(ESPRESSO);
    }
}

interface CoffeeMachine {
    Coffee brewCoffee(CoffeeSelection selection);
}

public class BasicCoffeeMachine implements CoffeeMachine {
    private BrewingUnit brewingUnit;

    @Override
    public Coffee brewCoffee(CoffeeSelection selection) {
        brewFilterCoffee();
    }

    private brewFilterCoffee() {
        brewingUnit.brew();
    }
}

public class PremiumCoffeeMachine implements CoffeeMachine {
    private Grinder grinder;
    private BrewingUnit brewingUnit;

    @Override
    public Coffee brewCoffee(CoffeeSelection selection) {
    switch(selection) {
        case ESPRESSO:
            return brewEspresso();
        case FILTER_COFFEE:
        default:
            return brewFilterCoffee();
        }
    }

    private brewEspresso() {
        grinder.grind()
        brewingUnit.brew();
    }

    private brewFilterCoffee() {
        brewingUnit.brew();
    }
}

Now that class is opened for extension (ItalianMachine, ColombianMachine, FrenchPressMachine) and closed for modification (won’t have a method with a different logic being added every time a new machine is added to the app).

Liskov Substitution Principle

A class can be replaced by its subclass in all practical usage scenarios, meaning that you should use inheritance only for substitutability.

Example

Using an Animal example

interface Animal {
    void fly();
    void swim();
}

public class Dog implements Animal {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }

    // But a dog cannot fly
    @Override
    public void fly() {
        throw new IllegalStateException();
    }
}

public class Hawk implements Animal {
    // A hawk cannot swim
    @Override
    public void swim() {
        throw new IllegalStateException();
    }

    // But a hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

Even though, both a Dog and a Hawk are animals, we can break up the inheritance to follow up this principle

interface Animal {
    void swim();
}

interface Bird {
    void fly();
}

public class Dog implements Animal {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }
}

public class Hawk implements Bird {
    // A hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

Interface Segregation Principle

A client shouldn’t be forced to implement an interface that it doesn’t use.

Example

Thinking about the last example, even though a Dog can only swim, some Animals can swim and fly.

Isn't easier if we just implement the interfaces like this

interface Swimmer {
    void swim();
}

interface Bird {
    void fly();
}

public class Dog implements Swimmer {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }
}

public class Hawk implements Bird {
    // A hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

public class Duck implements Swimmer, Bird {
    // A duck can fly
    @Override
    public void fly() {
       // Fly
    }

    // A duck can swim
    @Override
    public void swim() {
        // Swim
    }
}

Dependency Inversion Principle

We should invert the classic dependency between higher level modules and lower level modules, by abstracting their interaction.

Example

Let's say we have some implementations over a database

public class PersonService {
    private final PersonRepository personRepository;

    public PersonService(PersonRepository personRepository) {
        this.personRepository = personRepository;
    }
}

interface PersonRepository {
    Person findById(UUID id);
    Person create(UUID id, String name);
}

public class LocalRepository implements PersonRepository {
    private Map<UUID, Person> repository;

    // Implement the methods
}

public class DatabaseRepository implements PersonRepository {
    // Hibernate entity manager to handle the communication towards the Database.
    private EntityManager entityManager;

    // Implement the methods
}

In this way, the high-level PersonService doesn't care if you are using a LocalDatabase for development or a real database for production.

And for example, you can change your Hibernate implementation to another solution without your high-level service knowing what's going on.

In case if you have any questions or suggestions, feel free to send me a message

How did I move my pet project from Spring MVC to Webflux and Spring Native with GraalVM

Renato Fialho — Mon, 27 Jun 2022 23:35:26 +0000

You can read this post as well here

In my spare time last year, I created a pet project that aggregate news from some sources and delivers them to an Android app that I developed using Flutter, but that pet project is a topic for another post.

The backend for this pet project was firstly built using:

Kotlin
Gradle KTS
Spring Boot (Data, MVC, Security, Actuator)
PostgreSQL (Liquibase for migrations)
Deployed on a heroku free tier dyno (Validating the idea)

As I mentioned above, the stack is currently deployed in a Heroku free tier dyno, and that is a must for me to validate the idea for this project without spending tons of money.

The MVP was deployed in heroku using one of their buildpacks for Gradle and everything was working fine with some struggles:

1 - When I was enriching the DB (POSTing more content), the response times increased a little bit.

2 - Since it is a pet project, the dyno running my app sleep sometimes during the day, and the initialization was very slow (Around 14 seconds)

Those problems were already bothering me, and I already saw a couple things about the reactive stack for Spring (Webflux / R2DBC) that could help me handle more requests on a peak load without scaling my infrasctructure.

Usually on my pet projects, I try to implement some new ideas (On this one, I improved my knowledge in Kotlin and learned Dart and Flutter), but I wasn't 100% sure that Webflux and Spring Native were mature enough for being used in this project (Even though is a pet project, there are currently 500+ MAU)

Skipping some time, I went to the We Are Developers Worldwide Conference in Berlin a couple weeks ago, where a lot of talks were showcasing the new Spring Native and the already "known" Spring Webflux.

So then, I gave that stack a try and those are my learnings from it:

First mistakes

Those 2 technologies are somehow "new" and AFAIK, not being used in a lot of production grade environments.

Even the Spring project promises a lot of great improvements on Spring 6 and Spring Boot 3.0 for the GraalVM and Spring Native support.

With that being said, after some time, i realized that my first mistake was jumping into BOTH of the new technologies at the same time.

That created a feeling of not knowing if the issue was because of Webflux or Spring Native (I lost a couple nights of a lot of Stackoverflow and Github Issues trying to resolve the problems).

Then, I'll try to showcase the ones that I took notes and remember, please let me know if you faced other problems and we can spread the knowledge.

Heroku doesn't support Spring Native out of the box. Yet.

By it's nature of the AOT (Ahead of Time) compiler for the GraalVM, the Spring Native build consumes a lot of resources (It is a huge memory hog) and Heroku doesn't support it yet, so instead, you must build the image yourself or in your CI running ./gradlew bootBuildImage , that will use a buildpack to build and generate a Docker image for you with your application.

Then, you just need to tag it with the registry.heroku.com/<your_app_name>/<build> , push and run heroku container:release web -a <your_app_name>.

Heroku has Docker containers support out of the box, so then it is the same as deploying using one of theirs buildpack.

Spring Data Webflux and R2DBC drivers don't support a lot of nice features from relational databases

We know that Spring Webflux wasn't meant to be used with relational database since the JDBC drivers are I/O blocking, but the R2DBC initiative does it's job quite nicely.

Some features, such as the @OneToMany or @ManyToMany or @ManyToOne or @OneToOne are not supported (yet!) , and in order to make some things to work, you must add some annotations that are a little bit different, such as if you need auditing with the @CreatedAt and other annotations , you must add the @EnableR2dbcAuditing annotation.

Well, AFAIK, Quarkus and Micronaut already support some of those features with Native builds, so maybe this is something that Spring Data R2DBC will bring in the near future.

Liquibase is NOT supported. Yet.

My first thought when implementing this project was to literally "copy/paste" most of the code from the project that is currently successfully running.

And the database migration management tool that I was using is Liquibase (Wasn't a must, but instead, a good to have tool).

I started adding the Liquibase dependency and a lot of issues happened when building the native image, I resolved a lot of them but at the end, struggled with the fact that Liquibase currently doesn't support Spring Native with GraalVM out of the box, this is an issue for the future, hopefully when they chose their issue on Github, if you are interested, give a +1 on the thumbs up @ the issue!

Most of the monitoring tools are not available. Yet.

One issue for production grade applications is observability and monitoring, so far, I couldn't find any way to make the Newrelic java agent to work together with the GraalVM and Spring Native builds (So, no APM yet!). But you can still instrument your application using the Metrics provided by the actuator and Micrometer with the interfaces to the best providers in the market (Datadog, Newrelic, Prometheus and others).

You must provide some hints to the GraalVM, and some of them are not 100% clear

I faced an issue when running my application as a native app because the database URL was becoming malformed somehow, then, after a lot of research I found the samples repo from Spring that had a lot of tips to use Spring Native with some specific technologies.

The error that i was facing was an <unresolved> showing up from nowhere in the middle of my database URL:

Caused by: io.r2dbc.postgresql.PostgresqlConnectionFactory$PostgresConnectionException: Cannot connect to localhost/<unresolved>:5432

In my case, in order to use the R2DBC PostgreSQL and Spring Native, i had to add this hint to the GraalVM:

@NativeHint(
        trigger = PostgresqlConnectionFactoryProvider.class,
        types = {
                @TypeHint(types = { Instant[].class, ZonedDateTime[].class, URI[].class }, access = {}),
        }
)

You can have a META-INF/native/reflect-config.json file as well.

Results

Well, now, let's come to the results measured so far:

Before:

Started MyApplicationKt in 13.374 seconds (JVM running for 16.857)

Now:

Started MyApplication in 0.129 seconds (JVM running for 0.132)

I'll try to update this post later with some insights on CPU and Memory consumption, but so far, nothing to complain!

How to create slim docker Java Images using a minimal JRE

Renato Fialho — Thu, 14 Apr 2022 13:56:47 +0000

This can be read as well here

In this post, I will explain how you can create slim docker images by creating customized JREs using jlink and jmods.

Those commands are present on JDKs since Java 9, but actually being mature enough since Java 11, they bring a new way to create your customized JRE with only the modules that you need from Java, and then, creating smaller Docker images to run your Java applications (Mainly focused in Spring Boot applications), saving some good bucks in your Container Repository application (ECR, Artifactory, Docker Hub).

But, how do we start?

Assuming you already have a JDK installed in your machine, if not, i strongly suggest you to use sdkman.io and install Java 17 version (Which is the latest LTS as of the date of this post)

First of all, we need to get the list produced from jdeps based in your jarfile from Spring Boot, for example:

$ jdeps --list-deps --ignore-missing-deps  your-fat-jar.jar
   java.base
   java.logging

Well, that doesn't seems right, huh?

Spring Boot has a strategy by default to generate a fat jar with all the needed dependencies inside of it, and jdeps currently can't get all the dependencies recursively inside the jars from the fat-jar.

So, what you can do is to extract all the contents from the fat-jar and run jdeps against every jar in the lib folder.

Or, you can try with try and error, and see which ClassNotFoundException you will get from each JRE version

But, from some previous experience, we usually need those packages in our minimal JRE:

java.compiler
java.logging
java.sql
java.rmi
java.naming
java.management
java.instrument
java.security.jgss
java.net.http
jdk.httpserver
jdk.naming.dns

But my suggestion is to try yourself and see which packages you will really need in your slim JRE

Creating my Java slim JRE

You can use jlink locally to create your customized JRE, the command is somehow like this:

jlink \
    --module-path "$JAVA_HOME/jmods" \
    --add-modules [the java modules your application needs joined by ,] \
    --verbose \
    --strip-debug \
    --compress 2 \
    --no-header-files \
    --no-man-pages \
    --output /opt/jre-minimal

Explaining each flag:

--module-path <path>              Module path.
                                        If not specified, the JDKs jmods directory
                                        will be used, if it exists. If specified,
                                        but it does not contain the java.base module,
                                        the JDKs jmods directory will be added,
                                        if it exists.

--verbose                         Enable verbose tracing

--strip-debug                     Strip debug information

--compress=<0|1|2>                Enable compression of resources:
                                          Level 0: No compression
                                          Level 1: Constant string sharing
                                          Level 2: ZIP

--no-header-files                 Exclude include header files

--no-man-pages                    Exclude man pages

--output <path>                   Location of output path

You can get those informations as well by running jlinks --help in your command line tool.

But then, how do I create my slim Spring Boot application docker image

Well, take this as an example, as i mentioned, it's using the OpenJDK 17 version (Latest LTS by the time this post was written)

# Build our minimal JRE using jlink

FROM openjdk:17-oraclelinux8 as builder

USER root

RUN jlink \
    --module-path "$JAVA_HOME/jmods" \
    --add-modules java.compiler,java.sql,java.naming,java.management,java.instrument,java.rmi,java.desktop,jdk.internal.vm.compiler.management,java.xml.crypto,java.scripting,java.security.jgss,jdk.httpserver,java.net.http,jdk.naming.dns,jdk.crypto.cryptoki,jdk.unsupported \
    --verbose \
    --strip-debug \
    --compress 2 \
    --no-header-files \
    --no-man-pages \
    --output /opt/jre-minimal

USER app

# Now it is time for us to build our real image on top of an slim version of debian

FROM bitnami/minideb:bullseye

COPY --from=builder /opt/jre-minimal /opt/jre-minimal

ENV JAVA_HOME=/opt/jre-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"

VOLUME /tmp

# Copy the JRE created in the last step into our $JAVA_HOME

# For gradle
# COPY build/libs/app-*.jar app.jar

# For maven
# COPY target/app-*.jar app.jar


ENTRYPOINT ["java","-jar","/app.jar"]

But, how efficient is this?

For example, in a regular spring boot application, it saved 200Mb of storage for every image generated, from 543.03 to 349.98, assuming that you always have 10 versions of your application in your container registry, you can save 2 GB of storage space for each application!

You can check an example in this repo

Handling SIGTERM and SIGKILL on Spring Boot web applications

Renato Fialho — Wed, 08 Dec 2021 00:01:29 +0000

This post was reproduced here as well

When debugging one system recently, I found out that every time that a deploy, downscale, container rotation or k8s updates happened I had a lot of connection errors in the ingress car.

In common on those situations, is that k8s sends a SIGTERM, then have a grace period for the application to handle it gracefully, and after N seconds, it sends a SIGKILL, and that is the end.

At first, being a little bit reluctant that the issue was with Spring Boot or the web server that I run with (Tomcat), I tried to check every possible misbehave from the load balancer, no success.

One example on how this works, but mainly from AWS ECS:

Then, after some digging into the server properties in Spring Boot, we found out that the common behaviour for the web server is to shutdown immediately after receiving a SIGTERM, not waiting for any persistentkeep-alive connections to be properly finished and closed.

And how did I fix this?

So, in order to fix that, you must add a line to your application.properties or application.yml file like this:



    server.shutdown=graceful



server:
    shutdown: graceful

Passing graceful to the server shutdown property allows the web server to support graceful shutdown, allowing active requests time to complete and close any persistent keep-alive connections towards your service.

Oh, and if in any case you ended up here but want to know more how Quarkus handles this, i suggest you to take a look here, because it explains in an easy way how to implement this on Quarkus.