[BUG][JAVA] Invalid code generated: non-existent ApiClient is referred in toUrlQueryString

[sephiroth-j]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

After upgrading from v7.6.0 to v7.7.0, we have noticed that the generated code is invalid.

• The generated model class has an import of a class ApiClient which is not generated.
• The generated model class has a function toUrlQueryString(String) that uses a static function valueToString from the class ApiClient which is not generated.
  The old code was

joiner.add(String.format("%sfoo%s=%s", prefix, suffix, URLEncoder.encode(String.valueOf(getFoo()), StandardCharsets.UTF_8).replaceAll("\\+", "%20")));

The new code is

joiner.add(String.format("%sfoo%s=%s", prefix, suffix, URLEncoder.encode(ApiClient.valueToString(getFoo()), StandardCharsets.UTF_8).replaceAll("\\+", "%20")));

openapi-generator version

7.7.0

OpenAPI declaration file content or url

openapi: 3.0.3
info:
  title: Example API v1
  description: A reference API
  contact: {}
  version: 2.0.0
paths:
  /demo:
    get:
      responses:
        '200':
          description: Test
          content:
            'application/json':
              schema:
                type: object
                properties:
                  foo:
                    type: string

Generation Details

language: java
library: native

				<groupId>org.openapitools</groupId>
				<artifactId>openapi-generator-maven-plugin</artifactId>
				<version>7.7.0</version>
				<configuration>
					<generatorName>java</generatorName>
					<skipValidateSpec>false</skipValidateSpec>
					<generateApis>false</generateApis>
					<generateSupportingFiles>false</generateSupportingFiles>
					<generateModelTests>false</generateModelTests>
					<generateModelDocumentation>false</generateModelDocumentation>
					<generateApiTests>false</generateApiTests>
					<generateApiDocumentation>false</generateApiDocumentation>
					<output>${project.build.directory}/generated-sources</output>
					<configOptions>
						<sourceFolder>openapi</sourceFolder>
						<useJakartaEe>true</useJakartaEe>
						<withXml>true</withXml>
						<serializationLibrary>jackson</serializationLibrary>
						<library>native</library>
						<dateLibrary>java8</dateLibrary>
						<disallowAdditionalPropertiesIfNotPresent>false</disallowAdditionalPropertiesIfNotPresent>
					</configOptions>
				</configuration>
				<executions>
					<execution>
						<id>demo</id>
						<goals>
							<goal>generate</goal>
						</goals>
						<phase>generate-sources</phase>
						<configuration>
							<inputSpec>src/main/openapi/demo.yaml</inputSpec>
							<configOptions>
								<modelPackage>de.demo</modelPackage>
							</configOptions>
						</configuration>
					</execution>
				</executions>

Steps to reproduce

1. save the file above as src/main/openapi/demo.yaml
2. add the above plugin configuration to a maven pom
3. run mvn generate-sources
4. check target/generated-sources/openapi/de/demo/DemoGet200Response.java

Related issues/PRs

seems to be a regression from #18743
https://github.com/OpenAPITools/openapi-generator/pull/18743/files#diff-2eefc7a98c8e6aff3fa4589d8f2c364e7214c35e98806786e8dae207c42352df

Workaround

Set supportUrlQuery to false when toUrlQueryString is not needed.

[wing328]

@sephiroth-j thanks for reporting the issue

for your use cases, you only need the model files, right?

can you also generate the ApiClient.java as well (generateSupportingFiles set to true)? or you want to avoid extra dependencies in your model files?

[welandaz]

@sephiroth-j thanks for reporting the issue

for your use cases, you only need the model files, right?

can you also generate the ApiClient.java as well (generateSupportingFiles set to true)? or you want to avoid extra dependencies in your model files?

Hi @wing328 !

For our case, we do generate the ApiClient.java as well by default.
P.S. As a side note, we use a Gradle plugin and that doesn't seem to have the generateSupportingFiles option you mentioned.

[wing328]

can you push the auto-generated java client to a github repo so that I can take a further look?

[welandaz]

can you push the auto-generated java client to a github repo so that I can take a further look?

In our case, the class is generated and the valueToString function is present in it.
However, we do get an error that the package where the ApiClient.java resides does not exist.

[wing328]

https://github.com/OpenAPITools/openapi-generator/pull/18743/files#diff-2eefc7a98c8e6aff3fa4589d8f2c364e7214c35e98806786e8dae207c42352dfR5

did you set the invokerPackage?

[welandaz]

https://github.com/OpenAPITools/openapi-generator/pull/18743/files#diff-2eefc7a98c8e6aff3fa4589d8f2c364e7214c35e98806786e8dae207c42352dfR5

did you set the invokerPackage?

yes, we have that configured from the beginning

[wing328]

can you push the auto-generated java client to a github repo so that I can take a further look?

ideally with the spec and config options so that i can repeat the issue

[sephiroth-j]

@sephiroth-j thanks for reporting the issue

for your use cases, you only need the model files, right?

can you also generate the ApiClient.java as well (generateSupportingFiles set to true)? or you want to avoid extra dependencies in your model files?

Yes exactly, we are only interested in the model files. Other files, especially the ApiClient, are not needed/wanted.

[wing328]

@sephiroth-j

for your use case, you can use the workaround as you suggested since toUrlQueryString is only needed for API operations (e.g. making HTTP calls with query strings), right?

Set supportUrlQuery to false when toUrlQueryString is not needed.

[sephiroth-j]

Yes

[madorb]

Running into this as well due to the indicated regression.

[welandaz]

Just a note from our side: after having a deeper look, the root cause of the issue was related to our build setup. It came up because the model classes now depend on client one (e.g. ApiClient) which was not the case before, so we needed to include it explicitly for compilation.