[REQ] [jaxrs-spec] Migrate the quarkus library from RESTEasy Classic to Quarkus REST (and fix file upload types)

[Ignacio-Vidal]

Description

The quarkus library of jaxrs-spec generates for RESTEasy Classic (quarkus-resteasy), while current Quarkus defaults to Quarkus REST (quarkus-rest, formerly RESTEasy Reactive). One visible consequence is that file upload parameters are bound to a type Quarkus REST does not support.

Current output

public Response uploadFile(..., @FormParam(value = "file") InputStream _fileInputStream) {

Per the Quarkus REST guide, the supported multipart parameter types are FileUpload, java.nio.file.Path, java.io.File, byte[] and Buffer. InputStream is not among them. The idiomatic binding is:

public Response uploadFile(..., @RestForm(value = "file") FileUpload file) {

FileUpload also exposes the part metadata (fileName(), contentType(), size()), and it is the only one of these types that supports several files sharing one part name via List<FileUpload> — the shape produced by an array of format: binary properties (see #24452).

Why this is more than a type swap

pom.mustache for the quarkus library forks on useJakartaEe:

useJakartaEe	Quarkus platform	Namespace
true	3.0.1.Final	jakarta.*
false (default)	1.13.7.Final	javax.*

quarkus-rest and org.jboss.resteasy.reactive.* only exist on Quarkus 3.x, so a migration can only apply to the Jakarta branch. Two of the three quarkus samples do not set useJakartaEe and therefore resolve to Quarkus 1.13.7 (released 2021):

• samples/server/petstore/jaxrs-spec-microprofile-openapi-annotations — 1.13.7
• samples/server/petstore/jaxrs-spec-quarkus-mutiny — 1.13.7
• samples/server/petstore/jaxrs-spec/quarkus-security — 3.0.1

Version support context

Both versions the generator currently targets are long out of support. Per the Quarkus release schedule:

LTS	released	community support	status
3.33	25 Mar 2026	until 25 Mar 2027	active
3.27	24 Sep 2025	until 24 Sep 2026	active — oldest supported
3.20	26 Mar 2025	ended 28 Mar 2026	EOL
3.15	25 Sep 2024	ended 25 Sep 2025	EOL

So 3.27 is the oldest LTS still receiving active community support, with 3.27.4.1 as its latest micro. That makes it the most conservative target that is both supported and new enough to provide quarkus-rest (which does not exist before 3.9). The generator's current 3.0.1.Final and 1.13.7.Final are both well past EOL — 1.13.7 dates from 2021.

Questions for maintainers

1. Should the quarkus library move to quarkus-rest under useJakartaEe=true, keeping the javax/1.13.7 path on RESTEasy Classic unchanged?
2. Should the two lagging sample configs be flipped to useJakartaEe=true so they exercise the modern stack, accepting a large javax.* → jakarta.* sample diff?
3. Is the useJakartaEe=false (Quarkus 1.13.7) path still worth supporting at all, given it is four years past EOL?
4. Should the Jakarta path target 3.27 (oldest active LTS, as in the draft PR) or 3.33 (newest LTS, supported until Mar 2027)?

This is a breaking change to generated signatures for existing quarkus users (InputStream _fileInputStream → FileUpload file), so it seems worth agreeing on scope before merging.

I have a draft PR implementing option 1 (Jakarta path only, javax untouched) and am happy to adjust it to whatever scope you prefer.

Related

• [jaxrs-spec][quarkus] Migrate the Jakarta path to Quarkus REST and fix file upload types #24455 — Migration to quarkus-rest and fixes arrays of format: binary
• [java][microprofile] Emit List<File> to upload multiple files when declaring an array of binary forms #24453 — the same array fix for the java/microprofile client

Note

samples/server/petstore/jaxrs-spec-quarkus-mutiny is not listed in .github/workflows/samples-jaxrs.yaml, so it is never compiled by CI. It may be worth adding regardless of the outcome here.

openapi-generator version

master (7.25.0-SNAPSHOT)

[Ignacio-Vidal]

Draft PR opened: #24455 — implements option 1 (Jakarta path only; the javax/1.13.7 path keeps RESTEasy Classic untouched). Left as a draft pending a decision on the scope questions above.