English for Quarkus Developers

Quarkus conversations often need to justify its build-time-heavy approach compared to traditional Java frameworks, so the vocabulary covers native image compilation, dependency injection at build time, and the startup-speed trade-offs teams weigh when adopting it.

Key Vocabulary

Build-time processing — Quarkus’s design philosophy of resolving as much configuration, dependency injection wiring, and reflection metadata as possible during the build, rather than at application startup. “Most of our startup time savings come from build-time processing — the framework already knows the bean graph before the app even runs, so there’s almost nothing left to resolve at boot.”

Native image — an ahead-of-time compiled executable produced via GraalVM that starts in milliseconds and uses a fraction of the memory of a traditional JVM process, at the cost of a much longer build. “For this serverless function, a native image is worth the extra build time — cold start goes from seconds down to milliseconds, which matters when it’s invoked on demand.”

CDI (Contexts and Dependency Injection) — the dependency injection standard Quarkus implements, but with bean resolution largely happening at build time instead of through runtime reflection, improving both startup speed and native image compatibility. “This CDI bean isn’t being found in the native image build — check whether it’s missing an annotation that would let build-time processing discover it properly.”

Reactive routes / Mutiny — Quarkus’s reactive programming model, using the Mutiny library to express asynchronous, non-blocking operations as composable pipelines rather than blocking thread-per-request code. “Don’t block this thread waiting on the database call — express it as a Mutiny pipeline so the reactive routes layer can handle many more concurrent requests per thread.”

Dev mode (live coding) — Quarkus’s development experience where code changes are picked up and recompiled automatically on the next request, without a manual restart, similar in spirit to hot reload in frontend tooling. “Just save the file — dev mode picks up the change on the next request, so you don’t need to restart the whole application to test this.”

Common Phrases

• “Is this slow startup because of build-time processing not kicking in, or is something else initializing at runtime?”
• “Do we actually need a native image for this service, or is JVM mode fine given how it’s deployed?”
• “Is this CDI bean missing something that prevents build-time resolution?”
• “Should this call be expressed reactively with Mutiny, or is blocking acceptable for this endpoint’s load?”
• “Are we in dev mode, or do we need to restart manually to see this change?”

Example Sentences

Justifying a native image build for a serverless workload: “Because this function scales to zero and restarts frequently, a native image’s millisecond cold start is worth the longer CI build time — the JVM’s startup cost was dominating our latency.”

Explaining a reactive refactor: “This handler was blocking a thread on every database call — rewriting it with Mutiny lets a single thread serve many concurrent requests instead of one at a time.”

Onboarding a new developer to the workflow: “Use dev mode while you’re iterating — code changes apply automatically on the next request, so you won’t be restarting the app after every small edit.”

Professional Tips

• Justify build-time processing with concrete startup-time numbers — it’s a stronger argument to stakeholders than a general claim about “faster performance.”
• Reserve native images for workloads where cold start or memory footprint genuinely matters — the longer build time isn’t worth it for a long-running, rarely-restarted service.
• Explain CDI build-time resolution when a bean mysteriously isn’t found in a native build — it’s usually a missing annotation or unreachable reflection path, not a runtime bug.
• Push blocking database or HTTP calls toward Mutiny-based reactive routes when throughput under load becomes a bottleneck, rather than just adding more threads.

Practice Exercise

1. Explain what build-time processing means and why it helps Quarkus achieve fast startup.
2. Describe a scenario where a native image is worth its longer build time, and one where it isn’t.
3. Write a sentence explaining to a teammate why a blocking database call should be rewritten using Mutiny.