Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.60%. Comparing base (fede3cd) to head (ba4b063).

@@           Coverage Diff           @@
##             main    #3097   +/-   ##
=======================================
  Coverage   92.60%   92.60%           
=======================================
  Files          85       85           
  Lines        3164     3164           
  Branches      775      775           
=======================================
  Hits         2930     2930           
  Misses        183      183           
  Partials       51       51           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

A use case for @JsonCreator without @JsonValue was described in the forum discussion linked from the ticket. But is there any use case for @JsonValue without @JsonCreator or should that combination still be disallowed?

While testing some possible use cases, I realized that @JsonCreator is actually optional, at least in some cases, as Jackson is smart enough to deserialize correctly a single value passed as constructor parameter for example. Here's the simplest case.

public class Email {
    private final String email;

    public Email(String email) {
        this.email = email;
    }

    @JsonValue
    public String getEmail() {
        return email;
    }

    @Override
    public String toString() {
        return email;
    }
}

So we should probably just look at @JsonValue, as verifying that a corresponding creator (with annotation or not) exists is not easy.

This version handles both serialization formats correctly (just comment out @JsonValue to verify):

public class Email {
    private String email;

    public Email() {}

    public Email(String email) {
        this.email = email;
    }

    @JsonValue
    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    @Override
    public String toString() {
        return email;
    }
}

Sounds like it would make sense to only look for @JsonValue since that's the one with an actual semantic meaning but ignoring @JsonCreator which has no semantic meaning but is used as a hint in multiple different cases.

Exactly. So I propose to:

• file a new bug
• remove @JsonCreator support completely from Hilla (does not break existing apps)
• cherry-pick to 24.6
• update docs

Makes sense though the cherry pick should be done only if we're over 99.99% certain that it will always be backwards compatible.

I proposed to cherry-pick since the user who reported on the forum cannot upgrade from 24.5 to 24.6 due to this.
I can't see which case could lead to incompatibility: a class which only uses one is currently unsupported. And for those who use both, we get the type from the return type of the method marked with @JsonValue.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud