quarkusio/quarkus · error · RuntimeException

Could not reflectively call JibContainerBuilder constructor

Error message

Could not reflectively call JibContainerBuilder constructor

What it means

When the Jib 'docker' build strategy is used, Quarkus creates a JibContainerBuilder for docker-daemon builds via reflection into Jib internals (a constructor taking ImageConfiguration and BuildContext, to work around Jib API limits). If the reflective lookup/instantiation fails for any reason (Jib version change, constructor not found, InvocationTargetException from the docker client setup), it throws RuntimeException("Could not reflectively call JibContainerBuilder constructor").

Source

Thrown at extensions/container-image/container-image-jib/deployment/src/main/java/io/quarkus/container/image/jib/deployment/JibProcessor.java:993

        } catch (Exception e) {
            log.error("Unable to build AOT enhanced container image for original " + baseImage, e);
            throw new RuntimeException(e);
        }
    }

    // we need this horrible back because of https://github.com/GoogleContainerTools/jib/issues/4134
    public JibContainerBuilder createPatchedInstance(ContainerImageJibConfig jibConfig, String baseImage) {
        try {
            Constructor<JibContainerBuilder> constructor = JibContainerBuilder.class.getDeclaredConstructor(
                    ImageConfiguration.class,
                    BuildContext.Builder.class);
            constructor.setAccessible(true);
            ImageConfiguration imageConfiguration = ImageConfiguration.builder(ImageReference.parse(baseImage))
                    .setDockerClient(new PatchedDockerCliClient(determineDockerExecutable(jibConfig), Collections.emptyMap()))
                    .build();
            return constructor.newInstance(imageConfiguration, BuildContext.builder());
        } catch (Exception e) {
            throw new RuntimeException("Could not reflectively call JibContainerBuilder constructor", e);
        }
    }

    private static class PatchedDockerCliClient extends CliDockerClient {

        public PatchedDockerCliClient(Path dockerExecutable, Map<String, String> dockerEnvironment) {
            super(dockerExecutable, dockerEnvironment);
        }

        @Override
        public DockerImageDetails inspect(ImageReference imageReference) throws IOException, InterruptedException {
            return new PatchedDockerImageDetails(super.inspect(imageReference));
        }

        private static class PatchedDockerImageDetails extends DockerImageDetails {

            /** Pattern matches a SHA-256 hash - 32 bytes in lowercase hexadecimal. */
            private static final String HASH_REGEX = String.format("[a-f0-9]{%d}", 64);

View on GitHub (pinned to e1c734241f)

Solutions

1. Check the full cause: NoSuchMethodException means a Quarkus/Jib version mismatch — align quarkus container-image-jib with the Quarkus BOM (do not pin a custom Jib version)
2. Upgrade/downgrade Quarkus to a version where the Jib integration matches the Jib dependency
3. If a custom Jib version is forced in dependencyManagement, remove the override
4. As a workaround use builder=docker for daemon builds, or fix the docker executable resolution (quarkus.jib.docker-executable-name / DOCKER_HOST env)

Example fix

// before: pom.xml overrides Jib, breaking reflective wiring
<dependency><groupId>com.google.cloud.tools</groupId><artifactId>jib-core</artifactId><version>0.20.0</version></dependency>
// after: let Quarkus manage the Jib version
<!-- remove the explicit jib-core version override -->

// confirm Quarkus and Jib versions are aligned before the build
String quarkusVersion = io.quarkus.runtime.util.ClassUtil.class == null ? null : null;
// simpler: check jib-core on the classpath matches what the quarkus BOM manages
var mvn = new ProcessBuilder("mvn", "dependency:tree", "-Dincludes=com.google.cloud.tools:jib-core").inheritIO().start();

try {
    dockerDaemonBuild();
} catch (RuntimeException e) {
    if (e.getMessage() != null && e.getMessage().contains("Could not reflectively call JibContainerBuilder")) {
        throw new IllegalStateException("Quarkus/Jib version mismatch or docker env issue; see cause: " + e.getCause(), e);
    }
    throw e;
}

When it happens

Trigger: quarkus.container-image.builder=jib with quarkus.jib.base-registry... / docker build mode; JibConstructors.resolve fails or constructor.newInstance(imageConfiguration, BuildContext.builder()) throws — most often because the quarkus-jib version was upgraded and Jib's internal constructor signature changed, or the docker CLI/determinable docker environment throws during ImageConfiguration building.

Common situations: Quarkus upgrade pulling a newer Jib whose internals no longer match ( NoSuchMethodException/IllegalAccessException wrapped), docker executable not found when determineDockerExecutable runs, patching of the docker CLI client failing in restricted environments.

Related errors

• Failed to read imageId
• Quarkus code generation phase has failed
• Unable to create container image
• Invalid digest or hash:
• Cannot read '<fieldName>' field from <object> of class <claz

AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/a633a4b3648922ce. Report an issue: GitHub.