Support "iPhone" style capitalized properties

[cowtowncoder]

A long-standing problem (I'll list a few existing issues outlining these) is that if the logical property (and matching field):

1. Starts with capitalized letter (like "Phone") OR
2. Has second letter capitalized (like "iPhone")

then there are no possible "getter"/"setter" methods from which property could be derived.
So there is either mismatch or duplication of properties because following won't match:

public class IPhoneBean {
    private String iPhone;

    // These infer property "iphone" as leading capitals are lower-cased
    public String getIPhone() { return iPhone; }
    public void setIPhone(String value) { iPhone = value; }
}

same would happen if field name starts with capital letter(s).

Existing issues:

• PropertiesCollector decapitilizes properties names when setter has two consecutive capital letters #2696 ("oAuth")
• Annotation to ignore serialization not working with particular variable name (like dLogHeader) #2835 ("dLogHeader")
• (lombok) Variable with the second capital letter is abnormal during serialization and deserialization #4093 ("mValue")

[cowtowncoder]

Proposed solution is to add secondary processing for POJOPropertiesCollector (I think) where

1. If Field or Creator parameter exists for name with first and/or second letter is capital-case
2. But said Field/CreatorParameter does not match any setter/getter
3. If so, loop through Getter/Setter properties (with no Field/CreatorParameter) and see if case-insensitive match works
4. If so, merge the two -- and use Field/CreatorParameter name (over getter/setter variant)

[JooHyukKim]

This could probably be another MapperFeature that disabled in jackson 2 but enabled in 3?

[cowtowncoder]

+1 for MapperFeature. If it's safe enough could consider enabling by default even for 2.20 (and leave ability to disable for unlikely edge cases). But that can be decided on once this gets implemened.

[JooHyukKim]

Ai-generated and personally filtered list of name candidates.
One I like is ACCEPT_I_PHONE_STYLE_PROPERTIES for being intitutitve?
WDYT

Candidate	Intention	Alignment with Jackson naming conventions	Notes
ALLOW_MIXED_CAPS_PROPERTY_MERGE	Allow merging when property names use MixedCaps (e.g., iPhone)	Consistent with ALLOW_EXPLICIT_PROPERTY_RENAMING	Emphasizes “allow” over “merge”
ACCEPT_IPHONE_STYLE_PROPERTIES	Accept property names whose second letter is uppercase	Follows ACCEPT_* pattern such as ACCEPT_CASE_INSENSITIVE_*	Very explicit about the pattern
UNIFY_MIXED_CAPS_PROPERTIES	Unify MixedCaps property variants into one logical property	UNIFY is novel but readable alongside USE_* enums	Clear but new verb
HANDLE_SECOND_CAP_PROPERTY_VARIANTS	Handle variants where the second character is capitalized	Few precedents for HANDLE_* prefix	Verbose
ALLOW_NON_STD_CAPS_MATCHING	Allow matching of non-standard capitalization variants	Aligns with other ALLOW_* flags	“Matching” sounds weaker than “merge”
COMBINE_CAMEL_CASE_VARIANTS	Combine CamelCase variants into a single property	No current COMBINE_* enum, but clear intent	New prefix
ACCEPT_CAMEL_MIXED_CAPS_PROPERTIES	Accept Camel/MixedCaps property variants	Similar to ACCEPT_CASE_INSENSITIVE_PROPERTIES	—

[k163377]

This problem often occurs with Kotlin as well.
It would be more useful if other cases could be handled without additional reflection by Kotlin, for example

   private final boolean isFoo;
   private final Boolean isBar;
   private final String baz-baz;

   public final boolean isFoo() {
      return this.isFoo;
   }

   @Nullable
   public final Boolean isBar() {
      return this.isBar;
   }

   @NotNull
   public final String getBaz-baz() {
      return this.baz-baz;
   }

[cowtowncoder]

@k163377 "is-getters" are problematic since Kotlin definition differs from Java beans. But this is bit different from issue I try to describe here.

It might be worth filing separate issue for, outlining exact expectation (I am guessing JSON property Jackson infers is "foo", but Kotlin tools would expect "isFoo" -- but that (or whatever expectation is) needs to be explicitly spelled out).

[cowtowncoder]

@JooHyukKim yeah, with quick look I kind of like "UNIFY_MIXED_CAPS_PROPERTIES". Or could have something along "FIX_LEADING_UPPER_CASE_NAMES" lines.

[JooHyukKim]

@k163377 I don't think baz-baz work as property in Kotlin? Or maybe I am missing something here.

[k163377]

@JooHyukKim
In Kotlin, properties can be defined as follows

val `baz-baz`: String

The code shared in the comment is the formatted result of decompiling to Java.

[cowtowncoder]

I don't think we need to support baz-baz (at least not at first), despite it being legal from Kotlin perspective -- it seems ok to require @JsonProperty for now. Unless it turns out easy/possible to support.

Not sure if the approach I have in mind could work, depends on when and how we apply Naming Strategies -- perhpas it does. Although likely single-leading character would be problematic there too, wrt x-ray -> logical "xRay" -> getter "getXRay()" -> mangled as "xray".

[JooHyukKim]

Okay I thought too simply. Makes sense. Modified accordinlgy with tests with correct behavior from my perspective

[k163377]

I don't think we need to support baz-baz (at least not at first)

Yes, even if it is allowed in the JVM, it may not be necessary to actively support it, as it is an impossible case in normal Java.