[Java] [SpringClient] Introduce setting for sealed oneOf interfaces for Spring clients #21586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #15586 by utilizing the functionality from the PR that introduced sealed functionality to the Spring server generation.
Introduces a new setting for the RestClient and WebClient code generator,
useSealedOneOfInterfaces
. When set totrue
it will create a sealed interface for interfaces that are generated for the settinguseOneOfInterfaces
.Due to how these interfaces are generated, I believe a current side effect is that any class implementing an interface will be set to
final
if this new setting is set to true (this stem from the fact that children reuse thevendorExtensions.x-implements
that is also used when one decorates a class with an interface. This could be solved by introducing an additional vendor extension for oneOf children. But I believe that this is a corner case, and that it is something that can be introduced later if the need is there.I initially considered extending
useOneOfInterfaces
fromtrue/false
totrue/false/sealed
or similar, to not increase the amount of configuration settings. But due to how broadly theuseOneOfInterfaces
is used and inherited, I decided against it.PR checklist
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.
master
(upcoming7.x.0
minor release - breaking changes with fallbacks),8.0.x
(breaking changes without fallbacks)@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08)