[BUG] [Spring] useOptional=true with byte[] field generates wrong equals for the field

vhbcm commented 2 months ago

Bug Report Checklist

[X] Have you provided a full/minimal spec to reproduce the issue? See https://github.com/vhbcm/openapi-spring-optional-bytes/blob/master/src/main/resources/api.yaml
[X] Have you validated the input using an OpenAPI validator (example)?
[ ] Have you tested with the latest master to confirm the issue still exists?
[X] Have you searched for related issues/PRs?
[X] What's the actual output vs expected output?

The field is private Optional<byte[]> mycontent = Optional.empty(); and the actual output in equals() is
```
@Override
public boolean equals(Object o) {
if (this == o) {
  return true;
}
if (o == null || getClass() != o.getClass()) {
  return false;
}
DTO DTO = (DTO) o;
return Arrays.equals(this.mycontent, DTO.mycontent);
}
```
As you can see, the this.mycontent is assumed to be array but it is not. It is Optional<byte[]> instead. The equals() template needs to take this into account.
[ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The generator with useOptional=true option and with format: byte generates Optional<byte[]> field for which it then generates wrong equals() method that does not take the Optional into account.

openapi-generator version

7.8.0 using Maven

OpenAPI declaration file content or url

openapi: 3.0.3
info:
  title: 'test'
  description: 'Test'
  version: 1.0.0
servers: []
paths:
  '/test':
    get:
      responses:
        200:
          description: OK
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/DTO'
components:
  schemas:
    DTO:
      properties:
        mycontent:
          type: string
          format: byte

Generation Details

Steps to reproduce

Checkout the project at https://github.com/vhbcm/openapi-spring-optional-bytes and run mvn clean install.

Related issues/PRs

This looks like similar kind of issue as #17935.

Suggest a fix

🤷🏿

rangarajl commented 2 months ago

The code generation in this case is fundamentally based on the JSON Schema specifications, which specifies to semantically annotate format as per the reference here: https://json-schema.org/draft/2020-12/json-schema-validation#section-8

Regarding this specific issue, binary data in JSON should be encoded as a base64 string. The schema isn't used to validate the payload directly, as documents containing binary data may include control characters that invalidate the JSON document. This encoding ensures proper handling of binary data within the JSON structure. A similar issue is highlighted here - https://github.com/mozilla/jsonschema-transpiler/issues/81

So not sure if format bytes is valid in the first place, please add any context which I might have missed here

vhbcm commented 2 months ago

The type: string with format: byte is also included in the spec. See the table in 4.4 Data Types: https://spec.openapis.org/oas/v3.0.3#data-types

vhbcm commented 2 months ago

rangarajl commented 1 month ago

Ok, there seems to be 2 sources for the OAS formats vs the JSON format specifications. While there are specific use cases to natively support base64 format in API specs such as:

Embedding images in HTML and CSS
Sending email attachments: Base64 encoding is used to send email attachments because SMTP was originally designed to only transport 7-bit ASCII characters.
SSL certificates See the value behind this for APIs dealing in this space, albeit niche - do see the rational behind this feature

OpenAPITools / openapi-generator