OpenAPITools/openapi-generator · error · IllegalArgumentException

Version %s of MicroProfile Rest Client is not supported or i

Error message

Version %s of MicroProfile Rest Client is not supported or incorrect. Supported versions are %s

What it means

Thrown by JavaClientCodegen.processOpts when microprofileRestClientVersion is not a key of the mpRestClientVersions map. The generator only ships pom templates for MicroProfile Rest Client '1.4.1', '2.0' (the default), and '3.0'; each key also decides the javax vs jakarta root package. The lookup happens right after convertPropertyToStringAndWriteBack, so the value must match one of those exact strings.

Source

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

        if (additionalProperties.containsKey(MICROPROFILE_FRAMEWORK)) {
            if (!MICROPROFILE_KUMULUZEE.equals(microprofileFramework)) {
                throw new RuntimeException("Invalid microprofileFramework '" + microprofileFramework + "'. Must be 'kumuluzee' or none.");
            }
//            this.setMicroprofileFramework(additionalProperties.get(MICROPROFILE_FRAMEWORK).toString());
        }
        convertPropertyToStringAndWriteBack(MICROPROFILE_FRAMEWORK, this::setMicroprofileFramework);

        convertPropertyToBooleanAndWriteBack(MICROPROFILE_GLOBAL_EXCEPTION_MAPPER, this::setMicroProfileGlobalExceptionMapper);
        convertPropertyToBooleanAndWriteBack(MICROPROFILE_REGISTER_EXCEPTION_MAPPER, this::setMicroProfileRegisterExceptionMapper);

        additionalProperties.put(MICROPROFILE_REGISTER_EXCEPTION_MAPPER, microProfileRegisterExceptionMapper);
        additionalProperties.put(MICROPROFILE_GLOBAL_EXCEPTION_MAPPER, microProfileGlobalExceptionMapper);

        convertPropertyToBooleanAndWriteBack(MICROPROFILE_MUTINY, this::setMicroprofileMutiny);

        convertPropertyToStringAndWriteBack(MICROPROFILE_REST_CLIENT_VERSION, value -> microprofileRestClientVersion = value);
        if (!mpRestClientVersions.containsKey(microprofileRestClientVersion)) {
            throw new IllegalArgumentException(
                    String.format(Locale.ROOT,
                            "Version %s of MicroProfile Rest Client is not supported or incorrect. Supported versions are %s",
                            microprofileRestClientVersion,
                            String.join(", ", mpRestClientVersions.keySet())
                    )
            );
        }

        if (!additionalProperties.containsKey("rootJavaEEPackage")) {
            String mpRestClientVersion = (String) additionalProperties.get(MICROPROFILE_REST_CLIENT_VERSION);
            if (mpRestClientVersions.containsKey(mpRestClientVersion)) {
                rootJavaEEPackage = mpRestClientVersions.get(mpRestClientVersion).rootPackage;
            }
            additionalProperties.put("rootJavaEEPackage", rootJavaEEPackage);
        }

        if (additionalProperties.containsKey(CONFIG_KEY)) {
            convertPropertyToStringAndWriteBack(CONFIG_KEY, this::setConfigKey);

View on GitHub (pinned to fcec517be3)

Solutions

Use one of the exact supported keys: 1.4.1, 2.0, or 3.0 (e.g. --additional-properties microprofileRestClientVersion=1.4.1)
If you omitted the option and still see the error, a config file is injecting a stale value — remove or update the microprofileRestClientVersion key there
Pick 3.0 when you need the jakarta.* namespace; 1.4.1 and 2.0 generate javax.* code
Verify the value has no whitespace/quotes when passed through JSON config or CI environment variables

Example fix

# before
openapi-generator-cli generate -g java -i api.yaml \
  --library microprofile --additional-properties microprofileRestClientVersion=1.2

# after
openapi-generator-cli generate -g java -i api.yaml \
  --library microprofile --additional-properties microprofileRestClientVersion=1.4.1

Defensive patterns

Strategy: validation

Validate before calling

Set<String> supported = Set.of("1.4.1", "2.0", "3.0");
String v = String.valueOf(opts.getOrDefault("microprofileRestClientVersion", "2.0"));
if (!supported.contains(v)) {
    throw new IllegalArgumentException("microprofileRestClientVersion must be one of " + supported + ", got: " + v);
}

Try / catch

try {
    generator.generate();
} catch (IllegalArgumentException e) {
    if (e.getMessage() != null && e.getMessage().contains("MicroProfile Rest Client")) {
        // surface supported versions to the user and fail fast
        throw new ConfigurationException("Unsupported microprofileRestClientVersion: " + opts.get("microprofileRestClientVersion") + ". Use 1.4.1, 2.0 or 3.0", e);
    }
    throw e;
}

Prevention

Pin the MicroProfile Rest Client version explicitly in configs instead of relying on defaults that shift between generator releases
Add a schema check for enum-valued options in your config-as-code pipeline
Never hand-assemble version strings; reuse values echoed from config-help

When it happens

Trigger: Passing --additional-properties microprofileRestClientVersion=1.3 (or 1.0, 1.1, 1.2, 2.1, 3.1, '2', '2.0.0') with -g java --library microprofile. Also triggered by config files that carry a version string from an older/newer generator release whose key set differed, or by values with trailing whitespace or different casing.

Common situations: Developers target a MicroProfile implementation whose Rest Client TCK level is 1.2 or 2.1 and assume any released version is accepted. Others migrate configs between generator versions where the supported set changed (e.g. 1.4.1 replaced older 1.x keys), or paste '2.0.0-FINAL' style OSGi/semantic versions instead of the plain key.

Related errors

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