Introduzione a Quarkus: perché gli sviluppatori Java stanno passando a Java supersonico

Per quasi tre decenni, Java è stata la forza dominante nello sviluppo di software aziendale. Il suo ricco ecosistema, la solida base orientata agli oggetti, l’indipendenza dalla piattaforma tramite Java Virtual Machine (JVM) e framework testati sul campo come Spring Boot lo hanno reso il re indiscusso dell’infrastruttura backend.

Tuttavia, il passaggio verso architetture cloud-native, orchestrazione Kubernetes, containerizzazione (Docker) e serverless computing (AWS Lambda, Knative) ha messo in luce una grave vulnerabilità nei tradizionali framework applicativi Java: elevato sovraccarico di memoria e tempi di avvio lenti.

Quando un microservizio deve scalare orizzontalmente da zero a 100 repliche in risposta a un picco di traffico o quando una funzione serverless viene eseguita su richiesta, attendere da 3 a 10 secondi per l’avvio di un processo Java non è accettabile. La moderna infrastruttura cloud richiede un avvio immediato e un consumo ridotto di memoria, caratteristiche tradizionalmente riservate a linguaggi come Go, Rust o Node.js.

Inserisci Quarkus: un framework Java nativo di Kubernetes progettato specificamente per GraalVM e OpenJDK HotSpot. Spesso soprannominato “Supersonic Subatomic Java”, Quarkus riprogetta radicalmente il modo in cui le applicazioni Java vengono compilate, avviate ed eseguite.

In questa guida approfondita, esploreremo il motivo per cui gli sviluppatori Java stanno adottando Quarkus, come Quarkus raggiunge tempi di avvio inferiori al secondo e impronte di micro-memoria, i meccanismi dell’architettura di Build-Time Optimization e come creare un microservizio reattivo pronto per la produzione in Java con Quarkus.

1. Il dilemma del cloud-native del Java tradizionale

Per capire perché Quarkus esiste, dobbiamo esaminare come funzionano i framework Java tradizionali come Spring Boot o Jakarta EE.

A. Gli elevati costi di inizializzazione del runtime

I framework Java tradizionali fanno molto affidamento sulla riflessione dinamica del runtime, sulla scansione del percorso di classe e sulla generazione di proxy:

1. Scansione classpath: durante l’avvio, la JVM esegue la scansione di ogni file JAR nel classpath per scoprire annotazioni come @Component, @Service, @Controller o @Entity.
2. Elaborazione e riflessione delle annotazioni: il framework utilizza la riflessione (Class.forName(), getDeclaredFields()) per creare un grafico in memoria di bean, proprietà di configurazione e dipendenze.
3. Creazione di proxy dinamici: CGLIB o ByteBuddy genera proxy bytecode dinamici nella memoria di runtime per supportare la programmazione orientata agli aspetti (AOP), la gestione delle transazioni del database (@Transactional) e i limiti di sicurezza.
4. Inflazione Metaspace e RSS: tutti i metadati, i descrittori delle classi riflesse e i proxy generati devono essere conservati in memoria all’interno del Metaspace e della Resident Set Size (RSS) della JVM.

Questo ciclo di riflessione del runtime richiede cicli CPU considerevoli e aumenta il consumo di memoria heap. Un servizio CRUD REST di base in Java tradizionale può facilmente consumare da 140 MB a 300 MB di RAM in modalità inattiva e impiegare da da 3 a 8 secondi per avviarsi.

B. La sanzione finanziaria nel cloud computing

Negli ambienti serverless e containerizzati, i fornitori di servizi cloud addebitano i costi in base a due parametri: memoria allocata (GB) e durata di esecuzione (millisecondi).

• Avvii a freddo: se una funzione serverless impiega 5 secondi per l’avvio, gli utenti finali riscontrano una latenza notevole e si paga per 5 secondi di calcolo di avvio inattivo.
• Densità e scalabilità dei pod: in un cluster Kubernetes con un nodo di lavoro dotato di 16 GB di RAM, puoi eseguire solo circa 40 istanze di microservizi Spring Boot tradizionali prima di esaurire la memoria. Se ciascuna istanza consumasse solo 15 MB di RAM, lo stesso nodo potrebbe ospitare oltre 800 istanze.

2. Architettura Quarkus: spostare il lavoro dal runtime al tempo di costruzione

Quarkus risolve il dilemma del cloud-native attraverso un cambiamento radicale del paradigma architettonico: spostando le operazioni dinamiche dal runtime al buildtime.

Elaborazione in fase di creazione (ottimizzazione anticipata)

Invece di eseguire la scansione del percorso di classe, l’analisi delle annotazioni e il cablaggio del grafico dei bean ogni volta che si avvia l’applicazione, Quarkus esegue tutte queste operazioni pesanti una volta durante la fase di creazione (mvn package o ./gradlew build).

1. Architettura di estensione e passaggi di creazione: Quarkus utilizza un framework di estensione collegabile. Durante la compilazione della tua applicazione, le estensioni Quarkus analizzano le annotazioni, generano bytecode statico ottimizzato e risolvono in anticipo i grafici di inserimento delle dipendenze.
2. Metadati precostituiti: tutti i metadati di inserimento delle dipendenze sono precalcolati. All’avvio dell’applicazione, Quarkus crea direttamente un’istanza delle classi precompilate senza invocare la riflessione o la scansione dei percorsi di classe.
3. Eliminazione del codice morto (Tree Shaking): durante il processo di creazione, Quarkus identifica le classi, i metodi e le librerie che non vengono utilizzate dall’applicazione e li elimina completamente.

Nel momento in cui viene prodotto il JAR dell’applicazione o il file binario nativo, tutto il sovraccarico di runtime è stato eliminato. La JVM carica semplicemente bytecode statici precablati e si avvia immediatamente.

3. Immagine nativa GraalVM rispetto all’hotspot OpenJDK

Quarkus fornisce un modello a doppia esecuzione: funziona eccezionalmente veloce su OpenJDK HotSpot standard, ma raggiunge il suo massimo potenziale di prestazioni quando compilato in un’immagine nativa GraalVM.

+-----------------------------------------------------------------------+
|                         Java Source Code (.java)                      |
+-----------------------------------------------------------------------+
                                    |
                                    v (Standard javac)
+-----------------------------------------------------------------------+
|                            Bytecode (.class)                          |
+-----------------------------------------------------------------------+
                       /                         \
                      /                           \
                     v                             v
   +----------------------------------+   +----------------------------------+
   |      OpenJDK HotSpot JVM         |   |     GraalVM Native Image (AOT)   |
   |  - JIT Compilation (C1/C2)       |   |  - Substrate VM                  |
   |  - Dynamic Class Loading         |   |  - No Classpath Scanning          |
   |  - Fast throughput, longer boot  |   |  - Millisecond boot, tiny RAM    |
   +----------------------------------+   +----------------------------------+

Compilazione anticipata (AOT) e VM con substrato

GraalVM Native Image prende il bytecode Java e lo compila direttamente in un file binario eseguibile autonomo specifico del sistema operativo (binario ELF su Linux, Mach-O su macOS, EXE su Windows).

• Presupposto a mondo chiuso: GraalVM presuppone che tutto il codice, le classi e le risorse raggiungibili siano noti al momento della creazione.
• Substrate VM: l’eseguibile nativo incorpora un motore runtime in miniatura chiamato Substrate VM, che gestisce la gestione della memoria, la pianificazione dei thread e la garbage collection senza avviare un’istanza JVM completa.
• Zero costi di riflessione: poiché Quarkus prepara le configurazioni di riflessione e le definizioni proxy durante la fase di creazione, la compilazione delle immagini native di GraalVM avviene senza problemi senza i file di configurazione manuale storicamente richiesti dalle build native di GraalVM.

4. Benchmark delle prestazioni: l’evidenza empirica

Per illustrare il netto contrasto nelle prestazioni, esaminiamo i confronti dei benchmark standard del settore tra tre configurazioni di runtime Java che eseguono un servizio CRUD REST + database standard:

1. Stack tradizionale cloud nativo (JVM tradizionale/Spring Boot)
2. Quarkus sull’hotspot OpenJDK
3. Quarkus su immagine nativa GraalVM

Tabella riepilogativa delle prestazioni

Tieni presente che Quarkus compilato su un’immagine nativa si avvia in 14 millisecondi, più velocemente di un singolo battito di ciglia, e consuma solo 13 MB di RAM. Ciò rende Java pienamente competitivo con Go e Rust per le distribuzioni serverless e native del cloud.

5. Motore dual-core reattivo e imperativo

Storicamente, gli sviluppatori Java dovevano scegliere tra due modelli di programmazione reciprocamente esclusivi:

1. Imperativo (thread per richiesta): codice di blocco semplice e leggibile che utilizza driver JDBC standard ed endpoint REST sincroni.
2. Reattivo (Event Loop): codice asincrono e non bloccante (ad esempio, RxJava, Project Reactor) capace di un throughput elevato, ma noto per catene di callback complesse e debug difficile.

Quarkus unifica entrambi i mondi sotto un unico motore coeso alimentato da Eclipse Vert.x e Netty.

                      +---------------------------------+
                      |     Client HTTP Request         |
                      +---------------------------------+
                                       |
                                       v
                      +---------------------------------+
                      |       Eclipse Vert.x I/O        |
                      |          (Event Loop)           |
                      +---------------------------------+
                                   /       \
                                  /         \
                                 v           v
                 +-------------------+   +-------------------+
                 | Reactive Endpoint |   |Blocking Endpoint  |
                 | (Event Loop)      |   | (Worker Thread)   |
                 | - Mutiny (Uni/Multi)| | - Standard JDBC   |
                 | - Non-blocking    |   | - Imperative Code |
                 +-------------------+   +-------------------+

In Quarkus, l’I/O non bloccante è il fondamento. Se scrivi codice di blocco tradizionale, Quarkus invia automaticamente l’esecuzione a un pool di thread di lavoro gestito. Se utilizzi tipi reattivi come SmallRye Mutiny (Uni<T> e Multi<T>), l’esecuzione rimane sul thread del loop eventi non bloccante ad alte prestazioni.

6. Gioia dello sviluppatore: codifica in tempo reale e servizi di sviluppo

Oltre alle prestazioni di runtime, Quarkus offre un’esperienza di sviluppo rivoluzionaria progettata per eliminare il noioso ciclo di feedback build-test-riavvio.

A. Codifica live con riavvio zero (quarkus:dev)

Quando si esegue mvn quarkus:dev, Quarkus avvia la modalità di codifica live. È possibile modificare file Java, modificare proprietà, modificare modelli HTML o aggiornare schemi di database.

La prossima volta che attivi una richiesta HTTP nel tuo browser o terminale, Quarkus rileva le modifiche al file, applica nuovamente i passaggi di creazione e ricarica l’applicazione in meno di 500 millisecondi. Non è mai necessario arrestare e riavviare manualmente il server delle applicazioni durante lo sviluppo.

B. Quarkus Dev Services (contenitori di test a configurazione zero)

La connessione di un microservizio a un database PostgreSQL, a un broker Kafka o a una cache Redis in genere richiede la scrittura di un file docker-compose.yml e la configurazione delle porte del database locale.

Con i servizi di sviluppo Quarkus:

• Se Quarkus rileva una dipendenza dal database (ad esempio, quarkus-reactive-pg-client) ma non è configurato alcun URL del database in application.properties, Quarkus avvia automaticamente un contenitore Docker eseguendo PostgreSQL tramite Testcontainers in background.
• Inserisce automaticamente le credenziali di connessione nell’applicazione in esecuzione.
• Quando interrompi la modalità sviluppo, il contenitore si pulisce automaticamente.

7. Procedura dettagliata pratica: creazione di un servizio Quarkus reattivo pronto per la produzione

Creiamo un microservizio Quarkus pulito e ad alte prestazioni in Java che espone un’API REST connessa a un database PostgreSQL utilizzando Hibernate Reactive with Panache.

Passaggio 1: dipendenze del progetto (pom.xml)

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.ghaznix.quarkus</groupId>
    <artifactId>user-service</artifactId>
    <version>1.0.0-SNAPSHOT</version>

    <properties>
        <compiler-plugin.version>3.13.0</compiler-plugin.version>
        <maven.compiler.release>21</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <quarkus.platform.artifact-id>quarkus-bom</quarkus.platform.artifact-id>
        <quarkus.platform.group-id>io.quarkus.platform</quarkus.platform.group-id>
        <quarkus.platform.version>3.15.1</quarkus.platform.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>${quarkus.platform.artifact-id}</artifactId>
                <version>${quarkus.platform.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <!-- RESTEasy Reactive for high-performance HTTP endpoints -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-resteasy-reactive-jackson</artifactId>
        </dependency>

        <!-- Hibernate Reactive with Panache for active-record data access -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-hibernate-reactive-panache</artifactId>
        </dependency>

        <!-- Reactive PostgreSQL Driver -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-reactive-pg-client</artifactId>
        </dependency>

        <!-- Quarkus SmallRye OpenAPI / Swagger UI -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-smallrye-openapi</artifactId>
        </dependency>

        <!-- Testing -->
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-junit5</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>quarkus-maven-plugin</artifactId>
                <version>${quarkus.platform.version}</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Passaggio 2: definire l’entità reattiva (UserEntity.java)

Quarkus ha semplificato l’accesso ai dati con Panache, un’implementazione del modello Active-Record su Hibernate.

package com.ghaznix.quarkus.entity;

import io.quarkus.hibernate.reactive.panache.PanacheEntity;
import io.smallrye.mutiny.Uni;

import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.Table;
import jakarta.validation.constraints.Email;
import jakarta.validation.constraints.NotBlank;
import java.time.Instant;

@Entity
@Table(name = "users")
public class UserEntity extends PanacheEntity {

    @NotBlank(message = "Username cannot be blank")
    @Column(unique = true, nullable = false)
    public String username;

    @Email(message = "Email must be valid")
    @Column(unique = true, nullable = false)
    public String email;

    @Column(nullable = false)
    public String role;

    @Column(name = "created_at", nullable = false, updatable = false)
    public Instant createdAt = Instant.now();

    /**
     * Helper method to find a user reactively by email.
     */
    public static Uni<UserEntity> findByEmail(String email) {
        return find("email", email).firstResult();
    }
}

Passaggio 3: implementare la risorsa REST reattiva (UserResource.java)

Utilizzando RESTEasy Reactive e SmallRye Mutiny, i nostri endpoint HTTP funzionano in modo completamente asincrono su thread non bloccanti:

package com.ghaznix.quarkus.resource;

import com.ghaznix.quarkus.entity.UserEntity;
import io.quarkus.hibernate.reactive.panache.Panache;
import io.smallrye.mutiny.Uni;

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.validation.Valid;
import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;
import jakarta.ws.rs.core.Response;
import java.net.URI;
import java.util.List;

@Path("/api/v1/users")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@ApplicationScoped
public class UserResource {

    @GET
    public Uni<List<UserEntity>> getAllUsers() {
        return UserEntity.listAll();
    }

    @GET
    @Path("/{id}")
    public Uni<Response> getUserById(@PathParam("id") Long id) {
        return UserEntity.<UserEntity>findById(id)
                .onItem().ifNotNull().transform(user -> Response.ok(user).build())
                .onItem().ifNull().continueWith(() -> Response.status(Response.Status.NOT_FOUND).build());
    }

    @POST
    public Uni<Response> createUser(@Valid UserEntity user) {
        return Panache.withTransaction(user::persist)
                .replaceWith(() -> Response.created(URI.create("/api/v1/users/" + user.id))
                        .entity(user)
                        .build());
    }

    @DELETE
    @Path("/{id}")
    public Uni<Response> deleteUser(@PathParam("id") Long id) {
        return Panache.withTransaction(() -> UserEntity.deleteById(id))
                .map(deleted -> deleted 
                        ? Response.noContent().build() 
                        : Response.status(Response.Status.NOT_FOUND).build());
    }
}

Passaggio 4: configurazione dell’applicazione (application.properties)

# Quarkus Application Configuration
quarkus.application.name=user-service
quarkus.http.port=8080

# Database Schema Management (Automatically managed by Dev Services in dev mode)
quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.log.sql=true

# SmallRye OpenAPI & Swagger UI Configuration
quarkus.smallrye-openapi.path=/swagger-ui
quarkus.swagger-ui.always-include=true

Tieni presente che non abbiamo configurato URL, nomi utente o password di database! Quando esegui ./mvnw quarkus:dev, Quarkus rileva automaticamente PostgreSQL, avvia un contenitore Docker, configura le tabelle dello schema del database e apre l’interfaccia utente di Swagger in http://localhost:8080/swagger-ui.

Passaggio 5: creazione ed esecuzione di eseguibili nativi

Per eseguire in modalità sviluppatore Live-Coding istantaneo:

./mvnw quarkus:dev

Per creare un binario Linux nativo utilizzando GraalVM all’interno di un contenitore Docker (non è richiesta l’installazione locale di GraalVM):

./mvnw package -Dnative -Dquarkus.native.container-build=true

Per avviare il file binario risultante direttamente sul tuo sistema operativo:

./target/user-service-1.0.0-SNAPSHOT-runner

__  ____  __  _____   ___  __ ____  ______ 
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/ 
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \   
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/   
2026-08-26 01:37:15,102 INFO  [io.quarkus] (main) user-service 1.0.0-SNAPSHOT native (powered by Quarkus 3.15.1) started in 0.016s. Listening on: http://0.0.0.0:8080
2026-08-26 01:37:15,103 INFO  [io.quarkus] (main) Profile prod activated. 
2026-08-26 01:37:15,103 INFO  [io.quarkus] (main) Installed features: [cdi, hibernate-reactive, panache, reactive-pg-client, resteasy-reactive, resteasy-reactive-jackson, smallrye-openapi]

Avvio in 0,016 secondi!

8. Confronto delle caratteristiche strategiche: Quarkus vs. Spring Boot

9. Conclusione: è ora di passare a Quarkus?

Quarkus non è semplicemente un altro framework web; rappresenta l’evoluzione di Java per l’era del cloud-native. Combinando l’ottimizzazione in fase di compilazione con la compilazione nativa di GraalVM, Quarkus invalida lo stereotipo tradizionale secondo cui Java è troppo lento o troppo pesante in termini di memoria per i moderni microservizi e le funzioni serverless.

Quando dovresti scegliere Quarkus?

• Applicazioni serverless e basate su eventi: se distribuisci microservizi su AWS Lambda, GCP Cloud Run o Knative, i file binari nativi di Quarkus eliminano completamente i problemi di avvio a freddo.
• Cluster Kubernetes ad alta densità: se il conto della tua infrastruttura è dominato dal consumo di RAM del cluster, la migrazione dei servizi a Quarkus può ridurre i costi di memoria fino al 75%.
• Microservizi reattivi: se crei sistemi ad alto rendimento che richiedono streaming non bloccante (Kafka, gRPC, WebSocket), Quarkus offre prestazioni di alto livello immediatamente.

Java non è più vincolato da avvii lenti o tempi di esecuzione eccessivi. Con Quarkus, gli sviluppatori Java possono creare applicazioni cloud-native con velocità supersonica e impronta subatomica.