Unravel › Java concepts › Jakarta and other frameworks
Quarkus applications
Quarkus is a Java framework designed for containers and fast startup.
Learn these first
At a glance
Spring prepares the meal when guests arrive; Quarkus prepares as much as possible in the kitchen the day before (build time), so service is almost instant, and the dish can be frozen into a ready-meal (native image).
- 1You write standard Jakarta annotations: @Path resources, @Inject, @ApplicationScopedConfiguration comes from application.properties through @ConfigProperty(name = "greeting") or @ConfigMapping.
- 2PanacheEntity and PanacheRepository give active-record or repository style data access on top of Hibernate with minimal boilerplate: Order.find("status", s).list()
- 3Reactive and imperative styles coexist: Uni<T> and Multi<T> (Mutiny) for non-blocking code; @RunOnVirtualThread or @Blocking for blocking code that must not run on the event loop
- 4MicroProfile extensions come built in: @RegisterRestClient interfaces, fault tolerance (@Retry, @Timeout, @Fallback), metrics, health checks, and messaging with @Incoming and @Outgoing channels
- Because the bean graph is built at build time, reflection and dynamic class loading are limited
- Dev mode (quarkus dev) reloads code on change and provides continuous testing; use it, it is the main productivity feature
- The build step (Jandex index, extensions) performs classpath scanning, bean resolution, proxy generation and configuration parsing, and writes the results as bytecode
@Path("/greetings")public class GreetingResource { @ConfigProperty(name = "greeting.prefix", defaultValue = "Hello") String prefix; @GET @Path("{name}") @Produces(MediaType.TEXT_PLAIN) public String hello(@PathParam("name") String name) { return prefix + ", " + name; }}- line 3 uses ConfigProperty, the core of Quarkus applications
Read the full explanation (about 2 min)
Quarkus is a Java framework designed for containers and fast startup. It uses CDI and JAX-RS, moves work to build time (so startup takes milliseconds and memory stays small), and can compile to a native executable.
A mental model
Spring prepares the meal when guests arrive; Quarkus prepares as much as possible in the kitchen the day before (build time), so service is almost instant, and the dish can be frozen into a ready-meal (native image).
How it works
You write standard Jakarta annotations: @Path resources, @Inject, @ApplicationScoped. Configuration comes from application.properties through @ConfigProperty(name = "greeting") or @ConfigMapping.
PanacheEntity and PanacheRepository give active-record or repository style data access on top of Hibernate with minimal boilerplate: Order.find("status", s).list().
Reactive and imperative styles coexist: Uni<T> and Multi<T> (Mutiny) for non-blocking code; @RunOnVirtualThread or @Blocking for blocking code that must not run on the event loop.
MicroProfile extensions come built in: @RegisterRestClient interfaces, fault tolerance (@Retry, @Timeout, @Fallback), metrics, health checks, and messaging with @Incoming and @Outgoing channels.
Going deeper
Because the bean graph is built at build time, reflection and dynamic class loading are limited. Classes accessed reflectively (JSON serialization) need @RegisterForReflection for native builds; the failure only appears in native mode.
Dev mode (quarkus dev) reloads code on change and provides continuous testing; use it, it is the main productivity feature.
Blocking on the I/O thread (a JDBC call in a Uni pipeline without @Blocking) stalls the event loop; Quarkus detects some of these and logs a warning.
Under the hood
The build step (Jandex index, extensions) performs classpath scanning, bean resolution, proxy generation and configuration parsing, and writes the results as bytecode. At runtime the application starts from the pre-built state, and with GraalVM the whole thing is compiled ahead of time into a native binary with a closed-world assumption.
Common mistakes
- Missing reflection registration in native builds.
- Blocking calls on event-loop threads.
- Using Spring-style runtime proxies and expecting them to work.
- Skipping dev mode and continuous testing.
How Unravel recognises it
When you paste code, Unravel looks for these signs of quarkus applications. Spotting them yourself is a good habit when you read unfamiliar code:
- Annotations:
@QuarkusTest@QuarkusMain@ConfigProperty@RegisterForReflection@QuarkusIntegrationTest@Incoming@Outgoing@Channel@ConfigMapping@TestProfile@Blocking@NonBlocking@RunOnVirtualThread@RegisterRestClientand 1 more - Types:
PanacheEntityPanacheEntityBasePanacheRepositoryPanacheRepositoryBaseUniMultiQuarkusApplicationLaunchModeStartupEventShutdownEvent
Part of a learning path
- Jakarta EE and other frameworks · previous: JAX-RS (Jakarta REST) resources · next: Micronaut applications
Related concepts
Frequently asked questions
What is Quarkus applications?
Quarkus is a Java framework designed for containers and fast startup. It uses CDI and JAX-RS, moves work to build time (so startup takes milliseconds and memory stays small), and can compile to a native executable.
What are the most common mistakes with Quarkus applications?
Missing reflection registration in native builds. Blocking calls on event-loop threads. Using Spring-style runtime proxies and expecting them to work. Skipping dev mode and continuous testing.
How can I see Quarkus applications in real code?
Paste your own Java into Unravel and it will point out where quarkus applications appears, explain how it works at the detail level you choose, and draw the flow of the code around it.