OpenAPITools/openapi-generator · error · RuntimeException

Unable to locate /java-helidon/common/Status.java to discove

Error message

Unable to locate /java-helidon/common/Status.java to discover known HTTP statuses

What it means

Thrown by JavaHelidonCommonCodegen.loadKnownHttpStatusMap when the classpath resource /java-helidon/common/Status.java cannot be opened. The generator carries a copy of Helidon's Status.java inside its own JAR and regex-scans it to map numeric HTTP codes to Helidon constants (e.g. 404 -> NOT_FOUND) when building response records. A null InputStream means the generator JAR is broken or assembled without its template resources — it is an environment/packaging defect, not a user option error.

Source

Thrown at modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/JavaHelidonCommonCodegen.java:489

    /**
     * Prepares a map of predefined HTTP status code constants.
     * <p>
     * Helidon uses its own HTTP status type, and the Helidon code predefines many HTTP status code constants but also allows
     * ad hoc creation of other values based on the numeric status value. It's more efficient at runtime to use a constant
     * if it exists.
     * <p>
     * This method scans a copy of the Helidon Java file which contains the predefined constants and prepares a map
     * from the string representation of the numeric code to the Helidon constant name. This table allows us, when we are
     * generating the Response records for an operation, to use the Helidon predefined constant--if it exists--for the
     * response code declared for an operation in the OpenAPI document.
     * </p>
     *
     * @return prepared map
     */
    private HashMap<String, String> loadKnownHttpStatusMap() {
        try (InputStream is = getClass().getResourceAsStream("/java-helidon/common/Status.java")) {
            if (is == null) {
                throw new RuntimeException("Unable to locate /java-helidon/common/Status.java to discover known HTTP statuses");
            }
            Pattern statusPattern = Pattern.compile("public static final Status (\\w+)\\s*=\\s*new\\s*Status\\((\\d+)",
                    Pattern.MULTILINE);
            return new Scanner(is, StandardCharsets.UTF_8)
                    .findAll(statusPattern)
                    .collect(HashMap::new,
                            (map, match) -> map.put(match.group(2), match.group(1)),
                            Map::putAll);

        } catch (IOException e) {
            throw new RuntimeException(e);
        }
    }

    private void setHelidonVersion(String version) {
        helidonVersion = VersionUtil.instance().chooseVersionBestMatchOrSelf(version);
        setParentVersion(helidonVersion);
        helidonMajorVersion = VersionUtil.majorVersion(helidonVersion);

View on GitHub (pinned to fcec517be3)

Solutions

  1. Reproduce with the official distribution: openapi-generator-cli from npm/Homebrew/Docker — if it works, your packaging is the problem
  2. In a shaded JAR, add resource inclusion filters for java-helidon/** (maven-shade-plugin: keep src/main/resources transitively, do not exclude non-.class files)
  3. In IDEs, re-import the Maven/Gradle project and make sure modules/openapi-generator/src/main/resources is on the runtime classpath
  4. If embedding the generator, depend on the official org.openapitools:openapi-generator artifact rather than a re-packaged one

Example fix

<!-- before: maven-shade-plugin strips generator resources -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-shade-plugin</artifactId>
  <configuration>
    <filters>
      <filter>
        <artifact>*:*</artifact>
        <excludes>
          <exclude>**/*.java</exclude> <!-- also drops java-helidon/common/Status.java -->
        </excludes>
      </filter>
    </filters>
  </configuration>
</plugin>

<!-- after: only exclude bytecode we truly own, keep generator resources -->
<filter>
  <artifact>com.myco:codegen-wrapper</artifact>
  <excludes>
    <exclude>com/myco/**</exclude>
  </excludes>
</filter>
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: verify the generator JAR carries its template resources
try (InputStream is = JavaHelidonCommonCodegen.class.getResourceAsStream("/java-helidon/common/Status.java")) {
    if (is == null) throw new IllegalStateException(
        "Generator artifact is missing /java-helidon/** resources — use the official openapi-generator JAR, not a stripped/shaded rebuild");
}

Try / catch

try {
    new DefaultGenerator().opts(input).generate();
} catch (RuntimeException e) {
    if (e.getMessage() != null && e.getMessage().contains("java-helidon/common/Status.java")) {
        // environment/packaging defect, not a config error — do not retry with different options
        throw new IllegalStateException("openapi-generator artifact is broken: template resources absent from classpath. Use the official distribution.", e);
    }
    throw e;
}

Prevention

When it happens

Trigger: Running a custom/shaded openapi-generator JAR where resource merging excluded src/main/resources/java-helidon/** (aggressive shade or jarjar configs). Running from an IDE where the openapi-generator module's resources directory was excluded from the build path. Using a snapshotted/embedded generator pulled in as a dependency whose classifier stripped resources.

Common situations: Companies build a customized 'internal codegen service' by shading openapi-generator into a fat JAR and lose the non-class resources. IDE misconfiguration (marked-as-excluded resources, Gradle sourceSet tweaks) produces the same failure locally but not on CI with the official CLI.

Related errors

AI-assisted analysis of OpenAPITools/openapi-generator@fcec517be3 (2026-08-22). Data as JSON: /api/errors/62c0dbcc0d6a636a. Report an issue: GitHub.