Although the ProblemDetail#getTitle method was marked as nullable, the method never returned null because of unnecessary nested logic.
Basically, I would like to set custom title if the title of ProblemDetail null. Since title field does not have protected access variable I cannot change it by overriding the getTitle() method. Therefore, we actually have two solutions:
1. Change access modifier of title field in order to manipulate it from extended class.
2. Remove logic in the get method.
Comment From: sdeleuze
If I am not mistaken, I think null-safety needs to be consistent between the setter and the getter of a property otherwise it can cause issues, for example with how APIs are translated to Kotlin. Since the setter needs to be nullable, the fact the getter is nullable is likely on purpose.
The additional logic is here for a reason, so we can't just remove it because this would be useful for your use case. And that would be a breaking change, so I have to decline this PR.
If you are blocked in term of customization of the current behavior, you can create an issue with a reproducer for your use case that we can then review in order to decide if we should change something or not.
Comment From: haydin505
I understand that it would be a breaking change if we manipulate logic in the getter method of the title. Can we consider changing access modifier from private to protected? I can extend the ProblemDetail class and implement my custom logic into it. I can update pull request accordingly.
Comment From: sdeleuze
Please create a related issue describing your use case and proposal, pinging me and @rstoyanchev, and we will provide you a feedback.
Comment From: rstoyanchev
@haydin505 if I understand correctly you're asking for the field to be made protected? In the Spring Framework we don't expose fields for direct access via non-private modifiers. If you extend ProblemDetail, couldn't you give title a default value in the constructor? Or alternatively override the getTitle() method?