DEV Community: Anca

A quick Big O recap for devs

Anca — Mon, 09 Aug 2021 11:38:54 +0000

About a year ago, as I started doing some small recap on algorithms, I came to an interesting realization: as enterprise developers we don't give a lot of thought to the Big O Notation because we're constantly using and reusing frameworks and algorithms that are already implemented. It's certainly there in the back of our minds in order to be able to optimize, but it's not often "fully activated".

This year I'm preparing to become the buddy of a few students joining our company as part of their university studies. That means I'm putting together a study guide and an onboarding roadmap, but I also get to look back on all the things I wish I knew better when I was in their situation. Of course the learning path will not be that granular, but my mind wanders, so I dug up what used to be a tweet and turned it into a small article.
I hope this will be helpful for beginners, but also for devs that jumped straight into coding. And if you’re anything like me, you’ll enjoy following along with the growth chart.

Big O Notation

The Big O Notation is an abstract way to characterize algorithms according to how the running time or space (in memory or on disk) necessities grow as the size of the input grows.This is purely independent of programming languages, operating systems or hardware. Here is short sorted list of common growth rates:

Constant time - O(1) - The input size does not influence the required number of operations. Examples: printing a single value or accessing an array element by its index.
Logarithmic time - O(log n) - The number of required operations has a slow growth in relation to the input size. Example: binary search in a sorted array, where with each iteration the workload is being halved.
Square-root time - O(sqrt(n)) - The number or operations is proportional to the square root of the input size.Example: primality test.
Linear time - O(n) - The number of operations grows along with the size of the input.Examples: algorithms that involve iterating over a collection once, sequential search.
Log-linear time - O(n log n) - The number of operations grows proportionate to n log n. Example: merge sort.
Quadratic time - O(n²) - The number of operations is equal to a squared n, usually by running two nested for loops.Examples: bubble sort, insertion sort.
Exponential time - O(2ⁿ) - The number of operations doubles with every input increase.Example: finding Fibonacci numbers recursively.

Adding Fault Tolerance to your Quarkus Microservice with SmallRye

Anca — Sat, 12 Jun 2021 11:12:36 +0000

Introduction: Initial problem...

As we're gravitating more and more towards microservice architectures we notice that they tend to be inherently unreliable, and depending on the use case, even small outages could potentially make users impatient or determine them to seek better service somewhere else.
Although microservices bring their advantages to the game, they tend to rely a lot on each other and have interdependencies, so the issue of one of them potentially plummeting needs to be addressed and handled.

... and solution

It is becoming increasingly important that we build fault tolerant microservices, but we would also like tools that can make dealing with unreliability a little easier, all while allowing us to focus on the business logic, rather than ending up with stressful, intricate if-then-else statements.
This is where SmallRye Fault Tolerance comes into play by providing a standardized set of common failure-handling patterns via annotations that can make code readable and maintainable.
SmallRye Fault Tolerance is an implementation of Eclipse MicroProfile Fault Tolerance. It was originally based on Hystrix, the Netflix library for latency and fault tolerance in distributed systems, which heavily promoted the concepts of fault tolerance and isolation for microservices.
Hystrix has long been a very popular library in the industry, but the community activity has been declining and recently it came to a stop by announcing it would stop maintenance.
SmallRye Fault Tolerance is an easy-to-use extension that provides us with retry policies, timeouts, and circuit breakers that dictate whether and when executions should take place. It also includes fallbacks, which offer an alternative implementation when an execution does not complete successfully.

Let's have a look at it

What I'm using

Java 11
Apache Maven 3.8.1
IntelliJ IDEA
macOS Catalina

We'll simulate a little business logic in a delivery/logistics company that is dealing with managing and tracking transports. This is an overly simplified backend example, while also keeping itself realistic. The reason I chose a more complex model, rather than just a basic entity to pass around, is that I would like it to reflect the day-to-day image of an enterprise project.
I've talked about spinning up a Quarkus application here. You can add your extensions wherever you decide to create your project, be it directly on quarkus.io, in your IDE or via Maven command, like so:

mvn io.quarkus:quarkus-maven-plugin:1.13.4.Final:create \
                                       -DprojectGroupId=org.tinyg \
                                       -DprojectArtifactId=microprofile-fault-tolerance-quickstart \
                                       -DclassName="org.tinyg.TransportRest" \
                                       -Dpath="/transports" \
                                       -Dextensions="resteasy,smallrye-fault-tolerance,resteasy-jackson"

In an already existing Quarkus project you can just add the extension by running the following in your base directory:

./mvnw quarkus:add-extension -Dextensions="smallrye-fault-tolerance"

The full project can be found here, in the "initial" folder there will be a clean setup that needs to be enhanced and in the "final" folder we'll see the end version, with the desired improvements.
Let's have a quick look at the classes. For readability reasons I decided to make these sections collapsible so that they can be extended as needed.
Let's run the development server and see if it works:

./mvnw compile quarkus:dev

Model

import lombok.Getter;
import lombok.Setter;

import java.time.LocalDate;
import java.util.HashSet;
import java.util.Set;

@Setter
@Getter
public class Transport {

    private Long id;

    private String trackingId;
    private Set<Container> containers;

    private LocalDate departureDate;
    private LocalDate arrivalDate;

    public Transport(final Long id, final String trackingId, final LocalDate departureDate, final LocalDate arrivalDate) {
        this.containers = new HashSet<>();
        this.id = id;
        this.trackingId = trackingId;
        this.departureDate = departureDate;
        this.arrivalDate = arrivalDate;
    }

    public void addContainer(final Container container) {
        containers.add(container);
    }

}

import lombok.Getter;
import lombok.Setter;

import java.util.ArrayList;
import java.util.List;

@Setter
@Getter
public class Container {

    private Long id;

    private Transport transport;
    private List<ContainerLoad> containerLoad = new ArrayList<>();
    private ContainerType type;
    private String serialNumber;

    public Container(Long id, ContainerType type, String serialNumber) {
        this.id = id;
        this.type = type;
        this.serialNumber = serialNumber;
    }

    public void addContainerLoad(final ContainerLoad containerLoad) {
        if (ContainerType.PARTIAL_LOAD.equals(this.getType()) || this.containerLoad.isEmpty()) {
            this.containerLoad.add(containerLoad);
        }
    }
}

import lombok.Getter;
import lombok.Setter;

@Setter
@Getter
public class ContainerLoad {

    private Long id;

    private Container container;
    private Double weight;
    private Double height;
    private Double width;

    public ContainerLoad(Long id, Double weight, Double height, Double width) {
        this.id = id;
        this.weight = weight;
        this.height = height;
        this.width = width;
    }
}

public enum ContainerType {
    FULL_LOAD,
    PARTIAL_LOAD;
}

Service


import org.jboss.logging.Logger;
import org.tinyg.dao.TransportRepo;
import org.tinyg.exception.KnownProcessingException;
import org.tinyg.model.Transport;

import javax.enterprise.context.ApplicationScoped;
import javax.xml.ws.http.HTTPException;
import java.time.LocalDate;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
import java.util.concurrent.atomic.AtomicLong;
import java.util.stream.Collectors;

@ApplicationScoped
public class TransportService {

    private static final Logger LOGGER = Logger.getLogger(TransportService.class);
   private static final Random RANDOM = new Random();

    private TransportRepo transports;

    private AtomicLong counter = new AtomicLong(0);

    public TransportService() {
        transports = new TransportRepo();
    }

    public List<Transport> getAllTransports() {
        extraValidationOrProcessing();
        LOGGER.info("Information fetched successfully.");
        return new ArrayList<>(transports.values());
    }

    public List<String> getValidTrackingIds() {
        possibleFail();
        return transports.values().stream().filter(transport ->
                LocalDate.now().compareTo(transport.getArrivalDate()) <= 0).map(Transport::getTrackingId).collect(Collectors.toList());
    }

    private void possibleFail() {
        final Long invocationNumber = counter.getAndIncrement();
        if (invocationNumber % 4 > 1) { // alternate 2 successful and 2 failing invocations
            throw new RuntimeException("Service failed.");
        }
    }

    private void extraValidationOrProcessing() {
        // let's pretend there's a call to a different user service to check status/association with transports'
        // companies, etc
        if (RANDOM.nextInt(50) % 2 == 0) {
            LOGGER.error("The required information could not be retrieved right now.Try again.");
            throw new HTTPException(408);  //408 request timeout
        }
        if (40 <= RANDOM.nextInt(50)) {
            LOGGER.error(String.format("Something went wrong here at %s", LOGGER.getName()));
            throw new KnownProcessingException();
        }
    }

}

Rest


import org.jboss.logging.Logger;
import org.tinyg.exception.KnownProcessingException;
import org.tinyg.model.Transport;
import org.tinyg.service.TransportService;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import java.util.Collections;
import java.util.List;

@Path("/transports")
public class TransportRest {

    private static final Logger LOGGER = Logger.getLogger(TransportRest.class);

    @Inject
    TransportService transportService;

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public List<Transport> transports() {
        try {
            return transportService.getAllTransports();
        } catch (KnownProcessingException exception) { //we'll catch it like a bunch of responsible devs
            LOGGER.error(exception.getMessage());
            return Collections.emptyList();
        }
    }

    @GET
    @Path("/valid")
    @Produces(MediaType.TEXT_PLAIN)
    public List<String> getValidTransports() {
        return transportService.getValidTrackingIds();
    }

}

The model consists of 3 entities: Transport, which contains a set of Containers, which in turn, depending on their types, can contain one or more ContainerLoads.
The simple CDI bean will contain a data repository object. In real life, this would be handling queries to a database, but since that is not the main objective of this post, we'll do it like this for now. Finally, the TransportRest class is where we'll expose our endpoints, which we can call via Postman (or CURL command, or a browser) to get information about the transports. One of the REST methods is meant to be faulty, causing issues when trying to retrieve the list of available transports.

Retries

Sometimes one of our microservices may not behave as expected and has the potential to impact others if it becomes faulty. But not all situations are showstoppers and failures can be easily avoided just by calling the same service one more time. To prevent disturbing the upstream or the downstream, we can use the Retry mechanism, which will recover an operation from failure by invoking it again until it reaches its stopping criteria. To use this feature we just add the @Retry annotation to the faulty method, and by default we're introduced to some of the configuration parameters: maxRetries, retryOn, abortOn, delay. Let's explore these a little bit.
In the initial setup, an exception would be thrown some of the times when we try to retrieve a list of transports. We can annotate that method with @Retry, and based on what needs to be addressed, we can also configure it:

@Retry(
            retryOn = HTTPException.class, 
            maxRetries = 5,
            abortOn = KnownProcessingException.class,
            delay = 500
    )

What we're saying here is that we want to retry calling this method in case an HTTPException occurs. This one is pretty generic, but one can choose a more specific exception depending on their use case. The maximum times to retry this call will be 5, the delay between calls is 500 milliseconds, and under no circumstance should it be done again when an KnownProcessingException arises. The last exception is a custom one, just for demonstrating the functionality, but it highlights that there are ways of dealing with known, intentional failures as well (such as maintenance, for example). So now things will be different, upon trying to retrieve our list of transports, the console will look different and although communication with another service is not perfectly smooth, the user will not be aware of it. And if something happens that our functionality cannot continue, then that exception will be handled accordingly and the return value will be an empty list.

Timeouts

Let's imagine we have a functionality in the application that could display how much CO2 a means of transport is producing from point A to point B, based on the current load of containers and some other regional environmental factors. This is definitely not a crucial feature, it's mainly there for the users' information and also to show a commitment that future improvements are coming. So when the transport is being tracked, an updated panel of emissions will also be displayed.
In case the system is overloaded and the logic behind obtaining this data is too costly in terms of time, we can just go ahead without it and render the UI components.
We enhance our application with a new endpoint and a service class that will take care of that:

EmissionsCalculatorRest


import org.eclipse.microprofile.faulttolerance.Timeout;
import org.jboss.logging.Logger;
import org.jboss.resteasy.annotations.jaxrs.PathParam;
import org.tinyg.service.EmissionsCalculatorService;

import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import java.util.Random;
import java.util.concurrent.atomic.AtomicLong;

@Path("/emissions")
public class EmissionsCalculatorRest {

    @Inject
    EmissionsCalculatorService emissionsCalculatorService;

    private static final Logger LOGGER = Logger.getLogger(EmissionsCalculatorRest.class);
    private static final Random RANDOM = new Random();

    AtomicLong attempts = new AtomicLong(1);

    @GET
    @Path("/{trackingId}")
    @Timeout(2500)
    public String calculateEmissions(@PathParam String trackingId) {
        long started = System.currentTimeMillis();
        final long invocation = attempts.getAndIncrement();

        try {
            randomDelay();
            LOGGER.infof("EmissionsCalculatorService invocation #%d returning successfully", invocation);
            return emissionsCalculatorService.calculate(trackingId);
        } catch (InterruptedException e) {
            LOGGER.errorf("EmissionsCalculatorService invocation #%d timed out after %d ms",
                    invocation, System.currentTimeMillis() - started);
            return null;
        }
    }

    private void randomDelay() throws InterruptedException {
        Thread.sleep(RANDOM.nextInt(5000));
    }
}

EmissionsCalculatorService


import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class EmissionsCalculatorService {

    public String calculate(final String trackingId) {
        //Fetch transport based on trackingId.
        //Figure out the load.
        //Try to locate it based on last checkpoint.
        //Retrieve weather conditions, etc
        //Actual calculations...
        return "CO2 report has been computed.";

    }
}

An intentional delay has been set to occur somewhere between 0 and 5 seconds (normally we would not want to have such long waiting times, this is just easier to perceive as a human) and the timeout has been configured to 2.5 seconds.
Upon requesting this information a few times, we can see in the logs that some of them will time out with an org.eclipse.microprofile.faulttolerance.exceptions.TimeoutException. The successful ones will fetch us the information: "CO2 report has been computed.".

Fallbacks

Now is the best time to bring in a fix for the previous org.eclipse.microprofile.faulttolerance.exceptions.TimeoutException. Let's annotate the method with a @Fallback annotation and provide another function that could take over in case of failure. In our case, it can provide a simpler and faster calculation of emissions, or it could return a generic number that generally falls somewhere in the average values.

@GET
    @Path("/{trackingId}")
    @Timeout(2500)
    @Fallback(fallbackMethod = "genericInformationAboutCO2")
    public String calculateEmissions(@PathParam final String trackingId) {
...

}

Keep in mind that the fallback method needs to match the original one in terms of parameters, it would look something like:

private String genericInformationAboutCO2(final String trackingId) {
        return "An average consumption of 4,2 kg / 100 km corresponds to 4,2 kg x 2666 g/kg = 112 g of CO2/km.";
    }

By requesting this emissions data a few more times, we can see how well the fallback is handling it:

Circuit Breakers

If a part of our system becomes temporarily unstable we might want to cut access to it for a while in order to limit the number of failures. The job of a circuit breaker is to record successful and failed invocations of a method, and when the number of fails reaches a defined threshold, it cuts off invocations to that area. In the TransportService class we will have:

@CircuitBreaker(
            requestVolumeThreshold = 4,
            failureRatio = 1 / 2,
            delay = 10000
    )
    public List<String> getValidTrackingIds() {
        possibleFail();
        return transports.values().stream().filter(transport ->
                LocalDate.now().compareTo(transport.getArrivalDate()) <= 0).map(Transport::getTrackingId).collect(Collectors.toList());
    }

    private void possibleFail() {
        final Long invocationNumber = counter.getAndIncrement();
        if (invocationNumber % 4 > 1) { // alternate 2 successful and 2 failing invocations
            throw new RuntimeException("Service failed.");
        }
    }

By checking out the configuration parameters, we will see that requestVolumeThreshold is 4, meaning that the last 4 invocations will be checked. The failureRatio is 1/2 (default value), which indicates that a circuit breaker will open when 2 consecutive calls of the last 4 invocations fail. We set the delay to 10 seconds, which is how long the circuit breaker will stay open. Ten seconds was the value chosen so it can be easily perceived.
We can see in the logs that in this 10-second interval the circuit breaker is open and blocking any execution from happening.

When services are collaborating synchronously, there is a possibility that the called service may exhibit unavailability or high latency to the point that it becomes unusable. This can lead to precious resources such as threads and time being consumed for no reason, sometimes even going as far as exhaustion. A failing service in the application could potentially cascade into the failure of other services throughout the system, that's why it is important to be aware of possible downfalls and be prepared.

Adding a Fallback to your circuit breakers

Once we implement a circuit breaker, it might be desirable to also provide an alternative for the downtime. That can be achieved by supplying a fallback class. We once more use the @Fallback annotation:

@CircuitBreaker(
            requestVolumeThreshold = 4,
            failureRatio = 1 / 2,
            delay = 10000
    )
    @Fallback(CircuitBreakerFallback.class)

    public List<String> getValidTrackingIds() {

   ...

We then implement the FallbackHandler interface in our fallback class, where we override the "handle" method. Keep in mind that "handle" has to have the same return type as the annotated method.


import org.eclipse.microprofile.faulttolerance.ExecutionContext;
import org.eclipse.microprofile.faulttolerance.FallbackHandler;

import java.util.Collections;
import java.util.List;

public class CircuitBreakerFallback implements FallbackHandler<List<String>> {

    @Override
    public List<String> handle(ExecutionContext executionContext) {
        return getValidTrackingIds();
    }

    public List<String> getValidTrackingIds() {
        return Collections.singletonList("Has reached fallback for circuit breaker. You can provide and alternative " +
                "here.");
    }
}

We can now see that although the circuit breaker is open, an alternative implementation can take over and deal with the request.

Conclusions

And there you have it, we have seen some of the most useful and easy-to-use ways of keeping our applications afloat, even when it keeps running into trouble.

Resources

Why you should use Quarkus in your next microservice

Anca — Sun, 09 May 2021 23:09:17 +0000

Motivation

If you're lucky enough to work in a company where you can pitch ideas to your boss and teammates in a meet-up sort of setting, the following should help your argument in your next tech stack meeting. This article is part of an internal presentation I did for my team, in order to educate myself and also understand what the hype is all about.

What I'm using

Java 11
Apache Maven 3.6.3
IntelliJ IDEA
sdkman
macOS Catalina

So what is Quarkus?

The official definition goes like "A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards" - quarkus.io.
Sounds complex, right? Let's break it down a bit.

Supersonic - the main idea here is speed - fast booting, fast to respond to the 1st request, a time saver when it comes to changing and running code as a developer.
Subatomic - refers to size in terms of memory usage and reduced binary size.
Kubernetes Native - refers to the fact that it was designed for containers, meaning small binaries with fast startup. It also comes with Docker images and Kubernetes extensions for easy packaging and deploying.
Java - Quarkus is polyglot, supporting several JVM languages, like Groovy and Scala.
Libraries and Standards - the programming model is not new, it builds on top of existing standards. Quarkus is designed to work with popular frameworks, and libraries such as Eclipse MicroProfile and Spring, as well as RESTEasy (JAX-RS), Hibernate ORM (JPA), Apache Kafka, Spring, Elasticsearch, Camel, Infinispan, and many more.
HotSpot and GraalVM - it offers support for the most used JVM, as well as first-class support for GraalVM, which is important because it can compile an application down to a native binary, which makes it start faster and run on a smaller heap than a standard JVM.

Although still young (born in 2018), Quarkus comes from a company with a rich history of open source, Java runtimes, distributed environments, microservices, cloud environment, etc. - Red Hat. This makes it even more convenient if you're already using some of their services and plan on including your next Quarkus application.

What is the purpose and what problems does it solve

I think the clearest and simplest definition of its purpose that I came across belongs to Antonio Goncalves, and that is that it "pushes Java to the cloud".
To better understand this statement we only need to have a look back at the evolution of the industry, starting with the fact that Java transitioned from applets to server side monolithic applications. The machines that ran them were up 24/7 and memory usage was huge. Luckily the JIT compiler was there to optimize execution and the GC managed memory efficiently. Fast forward to today's mentality and you'll see that the direction we're going in comprises smaller and lighter components that we want to start/stop quickly and move around as we please. These are microservices and tiny functions that we can deploy, orchestrate and scale according to our needs. The future is now, we no longer scale up by adding CPU and memory, but rather by adding more instances with smaller binaries and low consumption.
Today, in a modern setup, either in the cloud or on premises, applications run on a container platform. On top of these you can run multiple JVMs, but they all have a relatively long startup time and consume resources. A lot of other technologies or native languages, that have low memory usage, are emerging in the cloud. For example, the density of NodeJS apps, for the same resources, is much higher than Java. In order to keep up with this demand, the purpose of Quarkus is to increase the density of applications, while preserving the good old Java platform that we love, by optimizing for fast startup times, small binaries, and low memory usage.

So let's talk performance in action

A nice thing to have with Quarkus is its integration with IntelliJ IDEA. If you're using a different IDE, no worries, bootstrapping a Quarkus application is made super easy by visiting quarkus.io. Click on "Start Coding" and you'll be provided with everything you need.
A third way to generate your project's backbone is by running:

mvn io.quarkus:quarkus-maven-plugin:1.13.3.Final:create \ -DprojectGroupId=com.example.demo \ -DprojectArtifactId=quarkus-demo \ -DclassName="com.example.demo.HelloResource" \ -Dpath="/hello"

I'll be using my IDE:

You can choose your desired build tool as well as a multitude of extensions, all from the comfort of your own IDE. Pretty cool, huh? Let's just take RESTEasy JAX-RS for now. You'll have all the needed instructions in the README.md file.
Now that your project is generated, you're all set.
Run ./mvnw compile quarkus:dev in your Terminal.
Depending on your setup, you'll probably have some dependencies downloaded and you'll see the message in your Terminal, that Quarkus has started with dev profile.
What you're interested in is this message:

So let's try out some live coding. You know what the original class looks like, we'll change it a bit, by renaming the endpoint from "hello" to "greeting", add a Logger and change the return message of the function. It will look like this:

import org.jboss.logging.Logger;
import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/greeting")
public class ExampleResource {

    @Inject
    Logger logger;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
       logger.info("You've called the renamed endpoint");
        return "Hello Quarkus";
    }
}

Don't forget about your tests in the ExampleResourceTest class. It should be adjusted like so:

@QuarkusTest
public class ExampleResourceTest {

    @Test
    public void testHelloEndpoint() {
        given()
                .when().get("/greeting")
                .then()
                .statusCode(200)
                .body(is("Hello Quarkus"));
    }
}

In a new Terminal tab, run curl http://localhost:8080/greeting
and you'll be able to see the result:

0.585s, not bad. Previously you would go grab another coffee, get on 9gag and scroll 15 more minutes past your build and deployment time.
Let's package the application by using mvn package and then run it with java -jar target/quarkus-app/quarkus-run.jar.
This will start your application with prod profile activated, in around 0.718s, even faster than initially with dev profile. The downside to this is that you don't get to hot-swap anymore, since you cannot change the application without packaging it, but it highlights exactly what we've discussed earlier, the capability of scaling as fast as possible.

The last and probably the most interesting part to see, regarding startup times, is building a binary with GraalVM. I highly recommend using sdkman (https://sdkman.io/ - an SDK manager that makes it a breeze to install and switch between Java versions.), and it should be as easy as sdk install java x.y.z-grl, after checking available distributions, and then sdk default java x.y.z-grl.
Once you have your GraalVM, run mvn package -Dmaven.test.skip=true -Pnative. It might take a little longer than you'd expect, as there's more work happening at build time now, but this is a topic I'd like to address in another post.The generated binary will be sitting in the target folder, ending in '-runner'.Let's try it out, by executing it like any command: ./target/demo1-1.0-SNAPSHOT-runner.

The starting time is 0.015 seconds, this is the actual moment we've been building up to. This is how quick and easy it is to scale up when experiencing high traffic at certain moments of the day.

Pros & Cons

I'll start with the cons, to get them out of the way, and end this post on a happy note.

New and not so well known - some might have reserves in trying it out right away since Quarkus does not quite have the reputation yet.
It will need proper migration from Jakarta EE - so you'll have to allocate proper resources for this.
Not all libraries compile with GraalVM yet - but it's ok for HotSpot JVM; if and when the time comes, switching should be one step away.

There might be some other impediments depending on your project's needs, but let's talk about all the great advantages you can have:

Developer Joy - with the hot reload, do we even need to argue in favor of this one?
Performance and cost savings - Quarkus’ low memory consumption and fast startup time translate into more efficient resource utilization and better user experience.
Reliability - Quarkus is built on the backbone of the proven and trusted enterprise Java ecosystem with an active user community with contributions from over 180 developers.
Reactive/Event-driven - ideal for reactive applications. It utilizes a non-blocking, reactive event loop for both imperative and reactive code meaning developers can choose the right option for their use case.
OpenShift integration - Quarkus is pre-integrated with OpenShift, which is providing a thriving environment for scalability and speed, and some companies have already adopted the platform.
Extension ecosystem - it provides lots of extensions that configure, boot, and integrate a framework or technology into your own application so developers can just focus on their code.

Conclusions

I know that "hello world" applications are not exactly reflecting reality, but the main point of this post is to highlight the potential of the Quarkus framework. Of course, everyone can decide, based on their use case, whether or not this is the right path for them, and perhaps the crucial point will be if or when they decide to move on from Jakarta EE.
As we've seen, getting started with Quarkus is really easy, there are plenty of good reasons to give it a try in your next application and if you ever get stuck, the available documentation is surprisingly comprehensive. What a time to be alive!
Since this framework is gaining a lot of traction, in the future I would like to tackle more topics related to Quarkus, as this is barely scratching the surface, and I believe it's an interesting subject, worth discussing.

Resources:

In my journey learning about Quarkus I have been using the following resources:

Quarkus Fundamentals by Antonio Goncalves - on Pluralsight
Thoughts on Quarkus by Sebastian Daschner on dzone.com
redhat.com - Quarkus dedicated pages
quarkus.io - guides