GoogleContainerTools/jib · error · UnsupportedOperationException

Getting the java version from a WAR file is currently not su

Error message

Getting the java version from a WAR file is currently not supported.

What it means

getJavaVersion for an exploded WAR is intentionally unimplemented: WAR archives do not carry Java version metadata the way Jib's Java layer processing expects. Any call throws UnsupportedOperationException.

Source

Thrown at jib-cli/src/main/java/com/google/cloud/tools/jib/cli/war/StandardWarExplodedProcessor.java:127

    }
    if (!resourcesLayer.getEntries().isEmpty()) {
      layers.add(resourcesLayer);
    }
    if (!classesLayer.getEntries().isEmpty()) {
      layers.add(classesLayer);
    }

    return layers;
  }

  @Override
  public ImmutableList<String> computeEntrypoint(List<String> jvmFlags) {
    throw new UnsupportedOperationException("Computing the entrypoint is currently not supported.");
  }

  @Override
  public Integer getJavaVersion() {
    throw new UnsupportedOperationException(
        "Getting the java version from a WAR file is currently not supported.");
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

Explicitly specify the Java version / base image (e.g. a JDK 17 Tomcat image) rather than letting Jib infer it from the WAR
Avoid querying getJavaVersion for WAR inputs; branch on application type before calling
Package as a JAR if Java-version inference is required

Example fix

// before
Integer v = processor.getJavaVersion();  // throws for WARs
// after
if (processor instanceof WarProcessor) { v = userSuppliedJavaVersion; }

Defensive patterns

Strategy: try-catch

Validate before calling

if (processor instanceof StandardWarExplodedProcessor) { javaVersion = explicitlyConfiguredVersion; } else { javaVersion = processor.getJavaVersion(); }

Type guard

boolean supportsJavaVersionLookup(JibProcessor p) { return !(p instanceof StandardWarExplodedProcessor); }

Try / catch

try { v = processor.getJavaVersion(); } catch (UnsupportedOperationException e) { v = configuredJavaVersion; }

Prevention

Always specify the base image/Java version explicitly for WAR builds
Avoid polymorphic calls to getJavaVersion across mixed app types
Document that WAR inputs require manual Java version selection

When it happens

Trigger: Any call to getJavaVersion() on StandardWarExplodedProcessor, typically when Jib's containerizing pipeline attempts to determine the target Java runtime version from a WAR input.

Common situations: Building with a WAR input where Jib tries to pick/validate the base image Java version; automated flows that query getJavaVersion for all application types.

Related errors

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/bcb845ed736c8c61. Report an issue: GitHub.