FasterXML / jackson-future-ideas

Repository for SOLE PURPOSE of issue tracker and Wiki for NEW IDEAS. Please: NO BUG REPORTS.
18 stars 6 forks source link

Support records as map keys without a @JsonDeserialize #62

Open nlisker opened 3 years ago

nlisker commented 3 years ago
record Point(int x, int y) {}

Map<Point, Object> map = ...

Because the map key is a composite class, Jackson needs a deserializer like

@JsonDeserialize(keyUsing = Point.Deserializer.class)
record Point(int x, int y) {

    public static class Deserializer extends KeyDeserializer {

        @Override
        public Object deserializeKey(String key, DeserializationContext ctxt) {
            ...
        }
    }
}

However, records are special. Their default serialization and string representation are known. In this case it's "Point[x=2, y=2]". This means that a deserializer could be synthesized for them without the user needing to specify one. Basically, it's "look inside [ ] and read the name=value pairs". If the user decides to override the string representation of the record, then it's on them to provide a matching deserializer.

nlisker commented 1 year ago

@cowtowncoder I see that Jackson 2.15 got several updates for records handling, but this didn't get any attention. The closest was https://github.com/FasterXML/jackson-databind/issues/3297. Should I have reported this on databind?

cowtowncoder commented 1 year ago

Sure, for sake of completeness, it's fine to request it there.

I suspect chances of this getting implemented would be slim but who knows? Serialization definitely can not/should not be what toString() gives (I'd be very much against trying to do that) but maybe others have better ideas.

nlisker commented 1 year ago

Serialization definitely can not/should not be what toString() gives

But toString() is what's used to serialize the key. Maybe the serialization part should also be configured especially for records?

cowtowncoder commented 1 year ago

Yeah we probably should rather fail than serialize using toString() -- that is only used since for many other datatypes it works adequately. That handling predates introduction of Records by about decade.

yawkat commented 1 year ago

seconding what @cowtowncoder says, i dont really see a good default string representation of records