Fix identification getters / setters for properties with second upper case symbol. For example eTemperature

[altro3]

Related issue https://github.com/micronaut-projects/micronaut-openapi/issues/1226

[altro3]

@graemerocher @dstepanov I've known about this problem for a long time, but usually got around it by simply renaming the fields. It's time to fix this bug

[graemerocher]

unlikely to happen before 5.x

[dstepanov]

This change might lead to wrong interpretation of the method like getorXyz as a property of OrXyz

[altro3]

@dstepanov your sample is invalid: in your method name you have 2 chars with lower case. This is contrary to Java naming conventions. Therefore the given method name will simply be ignored because it is not a getter.

The only naming restriction in Java is this: for names like MfIeld and mfIeld getter and setter method names will be the same:

public String getMfIeld() {
    ...
}
public void setMfIeld(...) {
    ...
}

But even this situation has no solution: according to Java convention, class attribute names must begin with a lowercase letter, so a field called MfIeLd contradicts this convention. Therefore, the name of the field for such getters and setters is always defined the same way: mfIeld Therefore, if the user decides to name the fields with a capital letter, and then uses a small letter, he breaks the rules and creates problems for himself.

But the name eTemperature does not contradict any principles, so it should be interpreted correctly

[altro3]

@dstepanov I want to say that now only one case of a correct getter name is not processed: When the first letter is lowercase, but the second letter is uppercase, that is, the first two letters in lowercase cannot be in the getter name.

Remember, I described to you the rules for naming getters and setters, in sufficient detail and identified 3 rules. So, then I only corrected the keyword with the _ symbol, but I did not correct the third point (which describes the case with the first lowercase character) in that merge request. Apparently in vain :-(

[altro3]

@graemerocher It doesn't matter. The main thing is, don’t forget about this fix. As I understand it, version 5 will be released no earlier than in 3 years

[CLAassistant]

All committers have signed the CLA.