[fix] [html] oneOf schema display in HTML2 generator

[johnny603]

Description

OpenAPI 3.0 specs with oneOf constructs containing mixed types (string + object) were producing unreadable output in HTML2 documentation
The issue was that technical strings like "oneOf<string,object>" were appearing in the generated HTML instead of human-readable text

Resolves: #4431

Root Cause Analysis

The issue was in the StaticHtml2Generator class which inherits from DefaultCodegen
The parent class's getSchemaType method calls toOneOfName() which returns technical format "oneOf<Type1,Type2>"
This technical format is not suitable for HTML documentation display

Solution Implemented

Added a custom override of the getSchemaType method in StaticHtml2Generator.java
The new method detects oneOf technical formats and converts them to human-readable text
Example transformation: "oneOf<string,object>" → "String or Object"

Key Implementation Details

Detection: Identifies strings starting with "oneOf<" and ending with ">"
Parsing: Extracts individual types from within the brackets
Formatting: Converts technical type names (string → String, object → Object, etc.)
Output: Joins types with " or " for clear, readable documentation

The HTML2 generator will now produce:

Before: oneOf<string,object> (technical, unreadable)
After: String or Object (human-readable, clear)

Mentions

@simllll

PR checklist

• Read the contribution guidelines.

• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.

• Run the following to build the project and update samples:
  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.

• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)

• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes Update swagger-parser to 2.0.1 #123" present in the PR description)

• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

thanks for PR

why remove "implements CodegenConfig"？

[johnny603]

The reason for this is that the class already extends DefaultCodegen, which itself implements the CodegenConfig interface. In Java, if a superclass implements an interface, any subclass automatically inherits that contract, so there’s no need to redundantly declare implements CodegenConfig in the subclass.

This change helps simplify the class declaration and avoids unnecessary repetition, while preserving all functionality and interface compliance. If you’d like confirmation or more detail, you can refer to the CodegenConfig interface and see that all generator classes in the repo follow this pattern.

[wing328]

I did a search for extends DefaultCodegen implements CodegenConfig and found that pretty much all other generators are doing extends DefaultCodegen implements CodegenConfig

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/18297637308/job/52463459619?pr=22088

Please fix the build failure when you've time.