liveBook · Manning

Build-time processing

As explained in Quarkus in Action

Build-time initialization is the evaluation of application or framework initialization logic during the build so its result can be embedded in the produced application.

Cloud applications may restart or scale up when traffic changes, making startup time and memory use important. Quarkus reduces repeated startup work by moving as much initialization as possible into the application build. The packaged application carries the results instead of repeating that work on every start. section 1.1 section 2.5

The build and runtime phases have different jobs:

  • During the build, Quarkus can load classes, scan annotations, process configuration, and inspect application code. section 1.1 section 2.5
  • Extensions can turn information gathered during the build into recorded bytecode for runtime execution. Code needed only by an extension’s deployment phase is not included in its runtime artifact. section 2.7.2 section 12.6
  • At startup, the application uses the packaged results rather than repeating the scans and calculations. This can shorten startup and reduce runtime memory use. section 1.1 section 2.5

Recording a GraphQL schema

A GraphQL extension can inspect model classes and their @Name annotations during the build, then record bytecode that directly constructs the schema. For a type named MyPersonType with a BirthDate field, the recorded code uses those known names rather than scanning the model again at startup. section 12.1.2

Listing 12.3 Decompiled bytecode produced by the example GraphQL extension
GraphQLType graphQLType = new GraphQLType("MyPersonType");
GraphQLField field = new GraphQLField("BirthDate", Date.class);
graphQLType.addField(field);

The decompiled bytecode makes the division of work concrete: it constructs the GraphQL type and field using names resolved during the build. section 12.1.2

To add build-time initialization, implement it in a Quarkus extension. A processor can calculate data during a build step, while a recorder captures code that will use that data. Choose STATIC_INIT where possible and RUNTIME_INIT otherwise: operations such as opening sockets cannot run in STATIC_INIT. In native mode, STATIC_INIT executes during image building; in JVM mode, both initialization modes execute when the application boots. section 12.3.5 section 12.3.4 section 12.6

How Quarkus in Action covers it

How deep it goes
Explains preprocessing and recorded bytecode through extension examples, including initialization timing, without detailing every operation eligible for STATIC_INIT.
Examples
Uses a generated GraphQL schema and a metadata endpoint whose JSON is calculated during a build step.
What it assumes
Assumes familiarity with Java applications while introducing extension build steps, build items, and recorders.
What you can do after
Build it from scratch in a Quarkus extension using a processor, build step, and recorder to package precomputed data.
How it connects
Connects build-time processing to Quarkus extensions, annotation scanning, bytecode recording, native compilation, and runtime initialization.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Quarkus in Action. The section links point to the parts of the book it draws on.