GoogleContainerTools/jib · error · IllegalArgumentException

`Main-Class:` attribute for an application main class not de

Error message

`Main-Class:` attribute for an application main class not defined in the input JAR's manifest (`META-INF/MANIFEST.MF` in the JAR).

What it means

When exploding a standard (non-Spring-Boot) JAR, Jib derives the container entrypoint from the `Main-Class` attribute in META-INF/MANIFEST.MF. If the attribute is absent, StandardExplodedProcessor.computeEntrypoint throws this IllegalArgumentException because it cannot construct a `java -cp ... main.Class` entrypoint.

Source

Thrown at jib-cli/src/main/java/com/google/cloud/tools/jib/cli/jar/StandardExplodedProcessor.java:98

            isResourceFile,
            JarLayers.APP_ROOT.resolve("explodedJar"));

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

  @Override
  public ImmutableList<String> computeEntrypoint(List<String> jvmFlags) throws IOException {
    try (JarFile jarFile = new JarFile(jarPath.toFile())) {
      String mainClass =
          jarFile.getManifest().getMainAttributes().getValue(Attributes.Name.MAIN_CLASS);
      if (mainClass == null) {
        throw new IllegalArgumentException(
            "`Main-Class:` attribute for an application main class not defined in the input JAR's "
                + "manifest (`META-INF/MANIFEST.MF` in the JAR).");
      }
      String classpath =
          JarLayers.APP_ROOT + "/explodedJar:" + JarLayers.APP_ROOT + "/dependencies/*";
      ImmutableList.Builder<String> entrypoint = ImmutableList.builder();
      entrypoint.add("java");
      entrypoint.addAll(jvmFlags);
      entrypoint.add("-cp");
      entrypoint.add(classpath);
      entrypoint.add(mainClass);
      return entrypoint.build();
    }
  }

  @Override
  public Integer getJavaVersion() {
    return jarJavaVersion;

View on GitHub (pinned to fb949e2676)

Solutions

Set Main-Class in the JAR manifest (e.g. Maven jar plugin `<archive><manifest><mainClass>` or Gradle `jar { manifest { attributes 'Main-Class': ... } }`) and rebuild
Use `jib.from`/entrypoint overrides or pass an explicit entrypoint instead of relying on manifest inference
If containerizing a library, add a wrapper main class or use a base image with a defined entrypoint

Example fix

// build.gradle (before)
jar { }
// after
jar {
  manifest { attributes 'Main-Class': 'com.example.Main' }
}

Defensive patterns

Strategy: validation

Validate before calling

try (JarFile jf = new JarFile(jarPath.toFile())) {
  if (jf.getManifest() == null || jf.getManifest().getMainAttributes().getValue(Attributes.Name.MAIN_CLASS) == null) throw new IllegalStateException("JAR has no Main-Class");
}

Try / catch

try { entrypoint = processor.computeEntrypoint(jvmFlags); } catch (IllegalArgumentException e) { if (e.getMessage().contains("Main-Class")) { entrypoint = userProvidedEntrypoint; } }

Prevention

Configure Main-Class in your build tool manifest settings
Verify `unzip -p app.jar META-INF/MANIFEST.MF` shows Main-Class before containerizing
Don't containerize library JARs as applications

When it happens

Trigger: Calling computeEntrypoint on an exploded standard JAR whose manifest has no `Main-Class:` main attribute (getMainAttributes().getValue(MAIN_CLASS) returns null).

Common situations: Packaging a library JAR (no main class) and trying to containerize it as an app; building with plain `jar`/Gradle/Maven without setting Main-Class; manifest overwritten by shading or repackaging plugins.

Understand the failure class

Background: "is required", "must be set", "missing required field": configuration validation errors across open-source libraries — this error's family across 36 libraries.

Related errors

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