Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support records as map keys without a @JsonDeserialize #62

Open
nlisker opened this issue Nov 25, 2021 · 5 comments
Open

Support records as map keys without a @JsonDeserialize #62

nlisker opened this issue Nov 25, 2021 · 5 comments

Comments

@nlisker
Copy link

nlisker commented Nov 25, 2021

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 nlisker changed the title Support records as map keys without a JsonDeserialize Support records as map keys without a @JsonDeserialize Nov 25, 2021
@nlisker
Copy link
Author

nlisker commented Jul 11, 2023

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

@cowtowncoder
Copy link
Member

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
Copy link
Author

nlisker commented Jul 11, 2023

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
Copy link
Member

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
Copy link
Member

yawkat commented Jul 12, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants