What’s New

Table of Contents

October 2025
September 2025
June 2025
- package-names from location
- generate response status annotation
April 2025
March 2025
November 2024
October 2024
June 2024
May 2024
April 2024
February 2024
Other years
- 2023 Releases
- 2022 Releases

October 2025

openapi-processor-spring/micronaut 2025.5

OpenAPI 3.2 support

this version adds OpenAPI 3.2 support. It does support the following OpenAPI 3.2 features:

$self
responses/…/…/…/itemSchema stream response (#314)
paths/…/query HTTP method (#313)
paths/additionalOperations/… custom HTTP methods (#313)

result mapping must not be a generic type

So far the result mapping required a generic wrapper class, like Spring ResponseEntity<>. It no longer has to be a generic wrapper. It allows a plain replacement class that will be used as the return type.

The current result mapping automatically assumes a generic wrapper class by default. To use a plain replacement type, i.e. no wrapper, it expects an arrow mapping:

plain ⇒ {target type}

which means, instead of the plain schema described in the OpenAPI response, use target type.

mapping.yaml

openapi-processor-mapping: v15

options:
  package-name: io.openapiprocessor.generated

map:

  paths:
    /foo:
       # standard, result wrapper with generic parameter
       result: org.springframework.http.ResponseEntity

       # new, mapping of plain replacement class
       result: plain => io.stream.Response

This allows to return types as Spring SseEmitter or Spring StreamingResponseBody from an endpoint implementation.

generate unreferenced schemas

By default, openapi-processor will only generate DTOs for schemas that are referenced by an endpoint.

It is now possible to generate DTOs from unreferenced schemas under component/schemas by setting the model-unreferenced option to true.

mapping.yaml

openapi-processor-mapping: v15

options:
  package-name: io.openapiprocessor.generated

  # default is false
  model-unreferenced: true

dependency updates

updated (internal) OpenAPI parser to 2025.5 (OpenAPI 3.2 support)
updated swagger parser to 2.1.34

September 2025

openapi-processor-spring/micronaut 2025.4

incompatibility when using `enum-type: framework` and `format-code`

when using enum-type: framework openapi-processor created a package-info.java which failed to format if format-code: true|google was enabled.

use $ref filename without json pointer as class name

the processor did create the class name of FooResponse based on the location as FooGetResponse200.java if the $ref did not have a json pointer.

It does now use the file name as class name if the $ref does not have a json pointer, i.e. in the example below the class name will be FooResponse instead of FooGetResponse200.

openapi.yaml

openapi: 3.1.0
info:
  title: get class name from file name
  version: 1.0.0

paths:
  /foo:
    get:
      responses:
        '200':
          description: the foo result
          content:
            application/json:
                schema:
                  $ref: 'FooResponse.yaml'

FooResponse.yaml

title: Foo Schema
type: object
properties:
  bar:
    type: string

mapping and bean validation annotations

the processor could produce invalid code that does not compile when combining a mapping with bean validation.

An OpenAPI (like the one below) with an integer parameter and bean validation enabled would add @DecimalMin & @DecimalMax annotations to the parameter in the generated code.

openapi.yaml

openapi: 3.1.0
info:
  title: drop bean validation annotation if mapped to unsupported type
  version: 1.0.0

paths:
  /foo:
    get:
      parameters:
        - in: query
          name: year
          schema:
            type: integer
            format: year
            minimum: 1970
            maximum: 2099

This is an issue if the parameter type is mapped to a different Java type.

openapi.yaml

openapi-processor-mapping: v15

options:
  package-name: generated
  bean-validation: jakarta

map:
  types:
    - type: integer:year => java.time.Year

In the example to java.time.Year, because both annotations are not supported on java.time.Year.

To fix this, the processor does not add it if it is not allowed.

In case the target type is not recognized automatically (and the annotations are dropped), for example on a custom java.lang.Number implementation, it is possible to tell the processor that an annotation is valid on that type.

mapping.yaml

openapi-processor-mapping: v15

options:
# ...

map:
# ...

bean-validation:
  jakarta.validation.constraints.DecimalMin:
    - other.CustomInteger
  jakarta.validation.constraints.DecimalMax:
    - other.CustomInteger

dropping parameters by OpenAPI name

dropping parameters did only work for parameters names if the OpenAPI name was identical to the Java name, i.e. no special characters. It does now handle special characters like -, _ or ` ` (space).

mapping.yaml

# ...

map:
 paths:
   /foo:
     get:
       parameters:
         - drop: foo-Param
         - drop: barParam

June 2025

openapi-processor-spring/micronaut 2025.3

package-names from location

it may not behave nicely if the expected configuration requirements are not met. It also works only with the INTERNAL OpenAPI parser (which is the default).

The package-names from location feature allows the processor to create package names based on the file location of $ref’erenced parts of the OpenAPI description.

This gets enabled by setting the package-names:location option.

openapi-processor-mapping: v13

options:
  # package-name: io.openapiprocessor.sample (1)

  package-names:
    base: io.openapiprocessor.openapi (2)
    # this enables package generation from the endpoint $ref file location
    location:  io.openapiprocessor.samples (3)

1	the shortcut for setting `package-names.base`. If location based packages should be used, setting `package-names.base` is preferred.
2	this is the base package for all generated code. This is identical to the current behaviour (i.e. `package-name`). Any file the is not below `package-names.location` will be generated with this as the base package.
3	`package-name.location` is the parent package name of the project’s target packages. If the processor finds a file ref’erenced from the main OpenAPI in a subpackage of `package-name.location` the generated sources will be generated with that package.

Here is an example layout to show what this is about.

The OpenAPI description of the endpoint foo is placed into the package where it will be implemented. The generated interface and resources get the package io.openapiprocessor.samples.foo.

The example shows only the controller implementation, but it could also contain service and repositories used to handle the foo endpoint. That way, everything related to that endpoint is in one place.

sample
\---- src
      +---- api
      |     +---- mapping.yaml
      |     \---- openapi.yaml
      \---- main
            +---- kotlin
            |     +---- io
            |     |     \---- openapiprocessor
            |     |           \---- samples
            |     |                 +---- foo
            |     |                 |     +---- FooController.kt
            |     |                 |     +---- foo.yaml
            |     |                 |     \---- resources.yaml
            |     |                 \---- bar
            |     |                       \---- ...
            \---- resources
                  \---- application.properties

The main OpenAPI file will look something like this:

# openapi.yaml
openapi: 3.1.0
info:
  title: openapi-processor sample api
  version: 1.0.0

servers:
  - url: "https://openapiprocessor.io/{path}"
    variables:
      path:
        default: api

paths:
  /foo:
    $ref: '../main/kotlin/io/openapiprocessor/samples/foo/foo.yaml' (1)

1	`foo.yaml` (the path item of `foo`) is $ref`erenced from the main OpenAPI description.

# io/openapiprocessor/samples/foo/foo.yaml
post:
  tags:
    - foo
  summary: echo a Foo.
  description: simple sample endpoint
  requestBody:
    $ref: 'resources.yaml#/FooBody'
  responses:
    '200':
      description: foo
      content:
        application/json:
          schema:
            $ref: 'resources.yaml#/Foo' (1)

1	and $references the `resource.yaml` in the same folder that describes the payload resource.

The package name of the foo endpoint files is io.openapiprocessor.samples.foo and the nearest parent package is io.openapiprocessor.samples. This is then the package-name option value.

It is possible to use io.openapiprocessor or even io as the parent package.

The generated files will still go to the output folder of the used build tool. No change there apart from the package names.

See also the spring-mvc-boot-4-packages-kt for an example setup.

generate response status annotation

the processor does now automatically generate a response status annotation for success responses (i.e., 2xx) not equal to 200.

This will conflict with manually added response status annotations.

To keep the old behavior, i.e., no automatically added annotations, set result-status: false on the global mapping level.

It is configured by adding it to the mapping section of the configuration file. It is available on all levels, i.e., global, endpoint and endpoint method.

openapi-processor-mapping: v15

options:
    # ...

map:
  # result-status: true is the default
  # setting it to false on the global level disables it
  result-status: false

  paths:
    # enable it for a specific endpoint
    /foo:
      result-status: true

      # ... or for a specific method of an endpoint
      #get:
      #  result-status: true

example:

openapi: 3.1.0
info:
  title: sample api
  version: 1.0.0

paths:
  /nop:
    get:
      tags:
        - nop
      summary: response status
      description: adds status for success other than 200
      responses:
        '204':
          description: no content

generates (with the framework-specific annotations):

package generated.api;

import annotation.Mapping;
import annotation.Status;
import generated.support.Generated;

@Generated(value = "openapi-processor-core",  version = "test")
public interface NopApi {

  /** response status adds status for success other than 200 */
  @Status(204)
  @Mapping("/nop")
  void getNop();

}

April 2025

openapi-processor-spring/micronaut 2025.2

support endpoint with different responses for different status codes

For the example below, versions before 2025.2 would pick Bar (the last response) as the return type for the getFooApplicationJson() endpoint method. This doesn’t work because the method must be able to return Foo or Bar.

To make this work it will now use Object as return type.

openapi: 3.1.0
info:
  title: test multiple success responses
  version: 1.0.0

paths:
  /foo:
    get:
      description: endpoint with multiple success responses
      responses:
        '200':
          description: success
          content:
            application/json:
                schema:
                  $ref: '#/components/schemas/Foo'
        '202':
          description: another success
          content:
            application/json:
                schema:
                  $ref: '#/components/schemas/Bar'

components:
  schemas:

    Foo:
      type: object
      properties:
        foo:
          type: string

    Bar:
      type: object
      properties:
        bar:
          type: string

marker interface for responses

The previous fix handles multiple response objects by using Object as the result type. An Object return type is not very descriptive. It is impossible to know from the interface which results are possible.

To improve on that situation, the processor can generate a marker interface that is more descriptive and helps with navigation in the IDE.

Generation of the marker interface is enabled by adding the response-interface option:

openapi-processor-mapping: v12

options:
  package-name: ...
  # ...
  response-interface: true

The marker interface is an empty interface, and its name is derived from the http method, path and content type to create a unique name.

If the response type (e.g., Foo from the above example OpenAPI) is used on multiple endpoints with multiple success response statuses, it will implement multiple marker interfaces.

package generated.model;

import com.fasterxml.jackson.annotation.JsonProperty;
import generated.support.Generated;

@Generated(value = "openapi-processor-core", version = "test")
public class Foo implements GetFooApplicationJsonResponse /* , .. more interfaces if Foo is used on multiple endpoints */ {

    @JsonProperty("foo")
    private String foo;

    // ...
}

That way it is possible to find the possible result type by navigating to the implementations of the marker interface.

drop OpenAPI parameter

It is now possible to drop a parameter given in the OpenAPI description from the generated code. This may be useful if a parameter is, for example, handled by a request filter and therefore is not needed in the endpoint method anymore.

To drop a parameter add a parameters/drop entry with the name of the parameter to drop it:

openapi-processor-mapping: v12

options:
  package-name: generated

map:
  paths:
    /foo:
      parameters:
        - drop: foo

Even if it is possible to add it at the global level, it is best used at the endpoint level.

result-style

the result-style option is now handled on all levels (global, endpoint, http method) and not just on the global level.

formatter selection

the processor didn’t use the new formatter selection, it does now properly handle google & eclipse (no need to for extra jdk configuration) values.

openapi-processor-mapping: v12
options:
  package-name: # ...
  format-code: false      # disable code formatter
  format-code: true       # use default google code formatter
  format-code: google     # use google code formatter, i.e. the same as "true"
  format-code: eclipse    # use eclipse code formatter

March 2025

openapi-processor-spring/micronaut 2025.1

do not generate accessors of pojos

It is now possible to disable generation of accessor methods on pojo dtos. The properties are still private. This is only useful in combination with an object annotation mapping that adds the accessors. For example lombok.Getter & lombok.Setter.

openapi-processor-mapping: v11

options:
  package-name: generated
  model-type: default           # i.e. pojo
  model-accessors: false        # only used if model-type is default

map:
  types:
    - type: object @ lombok.Getter
    - type: object @ lombok.Setter

package io.openapiprocessor.openapi.model;

import com.fasterxml.jackson.annotation.JsonProperty;
import io.openapiprocessor.openapi.support.Generated;
import java.util.UUID;
import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
@Generated(value = "openapi-processor-spring")
public class Foo {

    @JsonProperty("id")
    private UUID id;

}

schema mappings

It is now possible to restrict annotation mappings to schema properties by using schema level mappings. Schema mappings are only supported at the global level:

openapi-processor-mapping: v11

options:
  package-name: generated
  format-code: false

map:
  types:
    - type: integer:year => java.time.Year

  schemas:
    - type: integer:year @ com.fasterxml.jackson.annotation.JsonFormat(shape = com.fasterxml.jackson.annotation.JsonFormat.Shape.NUMBER_INT)

The schema mapping will tell the processor to apply the annotation only on dto properties:

package generated.model;

import com.fasterxml.jackson.annotation.JsonFormat;
import com.fasterxml.jackson.annotation.JsonProperty;
import generated.support.Generated;
import java.time.Year;

@Generated(value = "openapi-processor-core", version = "latest")
public class Foo {

    @JsonFormat(shape = JsonFormat.Shape.NUMBER_INT)
    @JsonProperty("year")
    private Year year;

    // ...
}

and not to the api endpoint method parameter:

 package generated.api;

 import generated.model.Foo;
 import generated.support.Generated;
 import java.time.Year;
 import org.springframework.web.bind.annotation.GetMapping;
 import org.springframework.web.bind.annotation.RequestParam;

 @Generated(value = "openapi-processor-core", version = "test")
 public interface Api {

     @GetMapping(path = "/foo", produces = {"application/json"})
     Foo getFoo(@RequestParam(name = "year", required = false) Year year);

 }

alternative code formatter

experimental (whatever is the use of formatting the generated code anyway.. ;-)

the current code formatter google-java-format uses internal java classes which requires additional configuration.

To avoid this additional configuration openapi-processor now supports the eclipse code formatter.

To support this the format-code option accepts two new values: google and eclipse.

openapi-processor-mapping: v11
options:
  package-name: # ...
  format-code: false      # disable code formatter
  format-code: true       # use default google code formatter
  format-code: google     # use google code formatter, i.e. the same as "true"
  format-code: eclipse    # use eclipse code formatter

javadoc improvement

improved javadoc generation for $ref with description.

# OpenAPI document

components:
  schemas:

    Foo:
      description: >
        this is the *Foo* schema description
      type: object
      properties:
        foo-bar:
          description: >
            *property* description
          type: string
        enum:
          description: >                                     (1)
            enum *property* description
          $ref: '#/components/schemas/FooEnum'

    FooEnum:
        description: "this is an *enum* description"
        type: string
        enum: ['foo', 'bar']

javadoc generation now handles a description (<1>) at $ref elements.

For the given OpenAPI description above the pojo for Foo will now look like this

package generated.model;

import com.fasterxml.jackson.annotation.JsonProperty;
import generated.support.Generated;

/**
 * this is the <em>Foo</em> schema description
 */
@Generated(value = "openapi-processor-core", version = "test")
public class Foo {

    /**
     * <em>property</em> description
     */
    @JsonProperty("foo-bar")
    private String fooBar;

    /**
     * enum <em>property</em> description
     */
    @JsonProperty("enum")
    private FooEnum aEnum;

    // ...
}

And for the record variant:

package generated.model;

import com.fasterxml.jackson.annotation.JsonProperty;
import generated.support.Generated;

/**
 * this is the <em>Foo</em> schema description
 *
 * @param fooBar <em>property</em> description
 * @param aEnum enum <em>property</em> description
 */
@Generated(value = "openapi-processor-core", version = "test")
public record Foo(
    @JsonProperty("foo-bar")
    String fooBar,

    @JsonProperty("enum")
    FooEnum aEnum
) {}

dependency updates

updated (internal) OpenAPI parser to 2025.1 (was 2024.7)
updated com.fasterxml.jackson:jackson-bom to 2.18.2 (was 2.18.1)

November 2024

openapi-processor-spring/micronaut 2024.6

trace mapping lookup

the processor can now create a log of the mapping lookup. It may help to understand failing mappings.

It adds two new options to control the logging.

openapi-processor-mapping: v10
options:
  package-name: # ...

map:
 # ...

logging:
  mapping: true
  mapping-target: stdout

logging.mapping enables the logging of the mapping lookups. mapping-target set the output channel. Simplest is to use stdout. The other possible value is logger. See the logging documentation for a more detailed description.

minimum/maximum and their exclusive version did not work for OpenAPI 3.1

fixed in the OpenAPI parser.

dependency updates

updated (internal) OpenAPI parser to 2024.6 (was 2024.5)
updated com.fasterxml.jackson:jackson-bom to 2.18.1 (was 2.18.0)
updated com.google.googlejavaformat:google-java-format to 1.24.0 (was 1.23.0)

October 2024

openapi-processor-spring/micronaut 2024.5

support for servers/server/url

it is now possible to tell the processor to generate a properties resource file with the path of a selected OpenAPI servers/server/url.

Given an OpenAPI description with a servers key:

openapi: 3.1.0
info:
  title: server url example
  version: 1.0.0

servers:
  - url: "https://openapiprocessor.io/{path}"
    variables:
      path:
        default: api
# ...

and a mapping

openapi-processor-mapping: v9
options:
  base-path:
    # false/true=0,1,2,... (default false)
    server-url: true

it will generate a properties file api.properties

openapi.base.path = /api

that can be used to configure the (Spring) context-path:

# application.properties

#spring.config.import = api.properties
server.servlet.context-path=${openapi.base.path}

See Server Url for more.

javadoc of `record`

a record should have its javadoc at the record using @param s to describe the record properties.

Instead of

/**
 * this is the <em>Foo</em> schema description
 */
@Generated(value = "openapi-processor-core", version = "test")
public record Foo(
    /**
     * <em>property</em> description
     */
    @JsonProperty("foo-bar")
    String fooBar
) {}

the processor now generates:

/**
 * this is the <em>Foo</em> schema description
 *
 * @param fooBar <em>property</em> description
 */
@Generated(value = "openapi-processor-core", version = "test")
public record Foo(
    @JsonProperty("foo-bar")
    String fooBar
) {}

warn on endpoint without success response

the processor ignores endpoints that have no success response (i.e. 2xx response code). To detect this "error" at compile time the processor will now print a warning with the effected endpoint.

type annotation mapping ignored with model-name-suffix

using a mapping like this:

openapi-processor-mapping: v9
options:
  model-name-suffix: Resource

maps:
  types:
    - type: Foo @ io.openapiprocessor.Annotation()

did not add the annotation because of the model-name-suffix.

dependency updates

updated (internal) OpenAPI parser to 2024.4 (was 2024.3)
updated com.fasterxml.jackson:jackson-bom from 2.17.1 to 2.18.0
updated com.google.googlejavaformat:google-java-format from 1.22.0 to 1.23.0

June 2024

openapi-processor-spring/micronaut 2024.4

add request body description to javadoc

The request body description is added as @param to the generated javadoc.

openapi: 3.1.0
info:
  title: javadoc
  version: v1

paths:
  /foo:
    get:
      requestBody:
        description: this is the request body
        # ...

missing `@Generated`

the generated Values and ValueValidator (used by enum-type string) were not annotated with @Generated.

missing import of class annotation parameter

using a .class parameter in a class annotation mapping did not add the import of the parameter class.

map:
  types:
    - type: Foo @ io.oap.ClassAnnotation(value = io.oap.Param.class)

In this example the import for Param was missing.

disable `@Generated`

its is now possible to disable the @Generated annotation. If it is disabled the processor will not add it to any generated type.

openapi-processor-mapping: v8

options:
  # ...

  # enable/disable generated annotation, true (default) or false.
  generated-annotation: false

control `@JsonProperty` annotation

By setting the json-property-annotation option is is possible to control the generation of the @JsonProperty annotation. It allows three values: always, auto or never.

always: (the default) adds a @JsonProperty annotation to all properties.
auto: only adds a @JsonProperty annotation to a property if it is required, i.e. if the OpenAPI property name is not a valid java identifier or if a property uses the readOnly/ writeOnly (OpenAPI) flags.
never: never adds a @JsonProperty annotation to the properties. This may generated invalid code if the property name is not a valid java identifier.

openapi-processor-mapping: v8

options:
  # ...

  # control @JsonProperty annotation, always (default), auto, never.
  json-property-annotation: auto

May 2024

openapi-processor-spring/micronaut 2024.3

response $ref did not work

using responses with `$ref`s did not work with all (supported) OpenAPI parsers.

internal OpenAPI parser did not work (the default parser).
openapi4j did not work (not maintained anymore).
Swagger parser worked.

It now works for all 3 (supported) OpenAPI parsers.

bad enum creation

the processor did not create a proper enum for an enum description like this:

components:
  schemas:
    AnEnum:
      type: string
      enum:
        - "1"
        - "2"

because 1 and 2 are not valid java identifiers, the processor generated

public enum Enum {
    INVALID("1"),
    INVALID("2");
    ...
}

The processor will now prefix invalid identifiers with "v" (value) to avoid this. The enum above will produce

public enum Enum {
    V1("1"),
    V2("2");
    ...
}

missing constraints with `null` mapping

using a null mapping:

openapi-processor-mapping: v7

options:
  bean-validation: true

map:
  paths:
    /foo:
      null: org.openapitools.jackson.nullable.JsonNullable

on a property

      properties:
        bar:
          nullable: true
          type: string
          maxLength: 4

did not add the constraint to the generated property.

dependency updates

updated (internal) OpenAPI parser to 2024.3 (was 2024.2)
updated swagger parser to 2.1.22 (was 2.1.21)

April 2024

openapi-processor-spring/micronaut 2024.2

setting the new compatibility options did not work

fixed setting the new compatibility options, it was always using the default values.

remove extra line feed in javadoc

removed the extra line feed (an empty line) in javadoc comments between summary and description.

optionally clear output directory

its is now possible to disable clearing of the targetDir when the processor is writing the generated files.

openapi-processor-mapping: v7

options:
  # ...

  # enable/disable deletion of targetDir: true (default) or false.
  clear-target-dir: false

February 2024

openapi-processor-spring/micronaut 2024.1

annotation mapping by OpenAPI extensions

it is now possible to use OpenAPI `x-`tensions to add additional annotations to schema properties:

Here is a simple schema that has x-`tensions on the `bar property.

openapi: 3.1.0
# ...
components:
  schemas:
    Foo:
      type: object
      properties:
        bar:
          type: string
          x-foo: single
          x-bar:
            - listA
            - listB

we can now map the `x-`tensions/values to annotations like this:

openapi-processor-mapping: v6
map:
  extensions:
    x-foo: single @ io.oap.FooA(value = "any")
    x-bar:
      - listA @ io.oap.FooB
      - listB @ io.oap.FooC

which will generate the additional annotations on the property:

package generated.model;

import com.fasterxml.jackson.annotation.JsonProperty;
import generated.support.Generated;
import io.oap.FooA;
import io.oap.FooB;
import io.oap.FooC;

@Generated(value = "openapi-processor-core", version = "test")
public class Foo {

    @FooA(value = "any")
    @FooB
    @FooC
    @JsonProperty("bar")
    private String bar;

    public String getBar() {
        return bar;
    }

    public void setBar(String bar) {
        this.bar = bar;
    }

}

annotation mapping by parameter name

another small improvement to annotation mapping is that we can add annotations by parameter name:

openapi-processor-mapping: v6
map:
  parameters:
    - name: foo @ annotation.Foo

reactive bean validation

the position of the @Valid annotation on reactive types has changed.

Until now the @Valid was placed on the generic type of the reactive wrapper, like this:

    @Mapping("/foo-flux")
    void postFooFlux(@Parameter Flux<@Valid Bar> body);

but validation did not happen with Spring. Spring needs the @Valid on the reactive wrapper to trigger the validation. Therefore @Valid is now placed by default on the reactive wrapper:

    @Mapping("/foo-flux")
    void postFooFlux(@Parameter @Valid Flux<Bar> body);

It should only take a bit annotation clean up on the interface implementations to adapt your code to the new @Valid position.

keeping the old behavior

To postpone the update, set the bean-validation-valid-on-reactive option to false.

openapi-processor-mapping: v6

options:
  # ...

compatibility:
  # optional, default is true
  bean-validation-valid-on-reactive: false

I would like to remove this option in the future. If you still need the old @Valid position please create an issue to help me understand why the old @Valid position is still useful.

identifier word breaks

the processor does now recognize a change from letter to number as a word break. The improves generation of camel case identifiers.

given an identifier from the OpenAPI description, the processor would generate the following names for different kinds of identifiers:

	OpenAPI	camel case	variable	class	enum
new	foo2Bar	foo2Bar	foo2Bar	Foo2Bar	FOO2_BAR
old	foo2Bar	foo2bar	foo2bar	Foo2bar	FOO2BAR

OpenAPI

camel case

variable

class

enum

new

foo2Bar

Foo2Bar

FOO2_BAR

old

foo2Bar

foo2bar

Foo2bar

FOO2BAR

keeping the old behavior

To postpone the update, set the identifier-word-break-from-digit-to-letter option to false.

openapi-processor-mapping: v6

options:
  # ...

compatibility:
  # optional, default is true
  identifier-word-break-from-digit-to-letter: false

Support Mono<ResponseEntity> as result type

previous versions allowed to configure a result wrapper (e.g. Spring ResponseEntity) and reactive types via single and multi mapping.

openapi-processor-mapping: v6

options:
   # ...

map:
  result: org.springframework.http.ResponseEntity

  single: reactor.core.publisher.Mono
  multi: reactor.core.publisher.Flux

Using both always wraps the reactive types with the result type. For example with Spring ResponseEntity (result type) and the reactor types Mono and Flux as

ResponseEntity<Mono<...>>
ResponseEntity<Flux<...>>

Unfortunately if you need the reactive result to modify the http response, something like this:

// does not work
public ResponseEntity<Mono<Result>> someEndpoint() {
    return someBean.getResult()
           .map(r -> ResponseEntity
                   .ok()
                   .eTag(r.eTag())
                   .body(Mono.just(r)));
}

it will not work because the final type of the statement is Mono<ResponseEntity<Mono<Result>>> and not the expected ResponseEntity<Mono<Result>>.

With this release we can fix that by setting the result mapping to

openapi-processor-mapping: v6

options:
  # ...

map:
  # wrap the ResponseEntity with Mono
  result: reactor.core.publisher.Mono<org.springframework.http.ResponseEntity>

  single: reactor.core.publisher.Mono
  multi: reactor.core.publisher.Flux

which will generate the endpoint signature as

public Mono<ResponseEntity<Mono<Result>>> someEndpoint() {
   // ...
}

and the above code will now work.

It is recommended to configure this on the endpoint level if you just need this for a few endpoints.

See also Spring ResponseEntity documentation.

What’s New

October 2025

OpenAPI 3.2 support

result mapping must not be a generic type

generate unreferenced schemas

dependency updates

September 2025

incompatibility when using enum-type: framework and format-code

use $ref filename without json pointer as class name

mapping and bean validation annotations

dropping parameters by OpenAPI name

June 2025

package-names from location

generate response status annotation

April 2025

support endpoint with different responses for different status codes

marker interface for responses

drop OpenAPI parameter

result-style

formatter selection

March 2025

do not generate accessors of pojos

schema mappings

alternative code formatter

javadoc improvement

dependency updates

November 2024

trace mapping lookup

minimum/maximum and their exclusive version did not work for OpenAPI 3.1

dependency updates

October 2024

support for servers/server/url

javadoc of record

warn on endpoint without success response

type annotation mapping ignored with model-name-suffix

dependency updates

June 2024

add request body description to javadoc

missing @Generated

missing import of class annotation parameter

disable @Generated

control @JsonProperty annotation

May 2024

response $ref did not work

bad enum creation

missing constraints with null mapping

dependency updates

April 2024

setting the new compatibility options did not work

remove extra line feed in javadoc

optionally clear output directory

February 2024

annotation mapping by OpenAPI extensions

annotation mapping by parameter name

reactive bean validation

keeping the old behavior

identifier word breaks

keeping the old behavior

Support Mono<ResponseEntity> as result type

Other years

2023 Releases

2022 Releases

incompatibility when using `enum-type: framework` and `format-code`

javadoc of `record`

missing `@Generated`

disable `@Generated`

control `@JsonProperty` annotation

missing constraints with `null` mapping