@JsonCreator ignored when deserializing map keys

[Trundle]

I'm unsure whether this is a bug or expected behavior, but I found it a bit surprising. Given the following class:

class Key {

    private final String value;

    private Key(final String value) {
        this.value = value;
    }

    @JsonCreator(mode = JsonCreator.Mode.DELEGATING)
    public static Key of(final String value) {
        return new Key(value);
    }
}

Then, when a Key value is deserialized, the factory method annotated with @JsonCreator is called as expected. If Key is used as a key in a Map though, the factory method is not called and Key's private constructor is used directly instead.

Key is of course reduced to demonstrate the issue and hence lacking all properties that would make it actually useful as a key in a map.

I tried the above with version 2.9.7. A repository demonstrating the issue can be found at https://github.com/Trundle/jackson-databind-oddity

[tbartley]

I have the same issue. I would like an explicitly annotated @JsonCreator to have precedence over any String constructor.

[cowtowncoder]

Handling of Map keys is a completely separate code path from handling of regular values, for better or worse (different kinds of serializer, deserializer are used), so that is probably the reason.
I don't remember off-hand whether Creators are supported at all for Map keys yet, but I guess that since private constructor is used there must be some support in there. If so, it might be easy enough to improve handling to use explicitly annotated creator: I agree that this would be the proper handling.

[tbartley]

Thanks for the reply.

They are supported, the code to choose a string deserialiser - and I (at least) only care about deserialising from a simple string value - is in StdKeyDeserializers:

    public static KeyDeserializer findStringBasedKeyDeserializer(DeserializationContext ctxt,
            JavaType type)
        throws JsonMappingException
    {
        // We don't need full deserialization information, just need to know creators.
        BeanDescription beanDesc = ctxt.introspect(type);

        // Ok, so: can we find T(String) constructor?
        Constructor<?> ctor = beanDesc.findSingleArgConstructor(String.class);
        if (ctor != null) {
            if (ctxt.canOverrideAccessModifiers()) {
                ClassUtil.checkAndFixAccess(ctor, ctxt.isEnabled(MapperFeature.OVERRIDE_PUBLIC_ACCESS_MODIFIERS));
            }
            return new StdKeyDeserializer.StringCtorKeyDeserializer(ctor);
        }
        /* or if not, "static T valueOf(String)" (or equivalent marked
         * with @JsonCreator annotation?)
         */
        Method m = beanDesc.findFactoryMethod(String.class);
        if (m != null){
            if (ctxt.canOverrideAccessModifiers()) {
                ClassUtil.checkAndFixAccess(m, ctxt.isEnabled(MapperFeature.OVERRIDE_PUBLIC_ACCESS_MODIFIERS));
            }
            return new StdKeyDeserializer.StringFactoryKeyDeserializer(m);
        }
        // nope, no such luck...
        return null;
    }

so it first looks for a single arg constructor from String, then looks for a factory method.

I'm trying a change where I just swap the order i.e. look for a factory method before the constructor against the current 3.0.0 snapshot but I'm blocked by an unrelated (at least, I can't imagine how it could be related) unit test failure atm so I've put my PR aside for a little while until I have time to debug that (SqlDateSerializationTest.testSqlDateConfigOverride:106->BaseTest.assertEquals:198 expected:<"1980+04+1[4]"> but was:<"1980+04+1[3]"> FWIW).

Would such an "swap the order" change be considered? Or is the risk of that breaking someone who's (unwittlingly) relying on a String constructor being preferred over a JsonCreator to high? Seems unlikely that would be the case as use of JsonCreator kind of implies coder wants that to be used for deserialisation.

Cheers,

Tim

[tbartley]

FYI, my use case is kind of like an extensible enum where I subclass CharSequence to make a kind of type safe String and only permit fixed set of values - same string value should resolve to same object instance so, while I have a constructor from String, it will fail when called a second time with the same value. So I have a valueOf creator that finds the existing instance if there is one and if not, only then constructs a new instance.

[zxdposter]

I have same issues

[Stephan202]

We hit this issue after enabling Immutables' interning functionality on some DTOs: lookups failed for deserialized maps with an interned key type.

One workaround that appears to work is to declare a custom KeyDeserializer with some code copied from StdKeyDeserializers#findStringBasedKeyDeserializer and StdKeyDeserializer, effectively skipping the constructor lookup. Example:

final class FactoryMethodKeyDeserializerModule extends SimpleModule {
    @Override
    public void setupModule(SetupContext context) {
        context.addKeyDeserializers(
                (type, config, beanDesc) -> {
                    Method factoryMethod = beanDesc.findFactoryMethod(String.class);
                    if (factoryMethod == null) {
                        return null;
                    }

                    if (config.canOverrideAccessModifiers()) {
                        ClassUtil.checkAndFixAccess(
                                factoryMethod,
                                config.isEnabled(MapperFeature.OVERRIDE_PUBLIC_ACCESS_MODIFIERS));
                    }

                    return new StdKeyDeserializer(-1, factoryMethod.getDeclaringClass()) {
                        @Override
                        public Object _parse(String key, DeserializationContext ctxt)
                                throws IllegalAccessException, InvocationTargetException {
                            // NB: `try/catch` can be dropped if FasterXML/jackson-databind#3109 is released.
                            try {
                                return factoryMethod.invoke(null, key);
                            } catch (InvocationTargetException e) {
                                if (e.getCause() != null) {
                                    Throwables.throwIfUnchecked(e.getCause());
                                }

                                throw e;
                            }
                        }
                    };
                });
    }
}

[cowtowncoder]

@Stephan202 thank you for sharing this!

[cowtowncoder]

Back to the very beginning, I will note that as of Jackson 2.12, there is introspection for 2 String-based Creators, neither of which actually considers @JsonCreator. Based on this, I would have thought original case simply worked:

1. Constructor that takes single String argument
2. Static factory method that takes single String argument

However, javadocs also suggest that for (2), name must be valueOf(). Code goes through so many paths that I got lost and while I could not find this limitation, I think I'd really need to write some unit tests to verify this.

I do think that @JsonCreator on 1-arg constructor or 1-arg factory method, taking CharacterSequence/String should work; this issue can remain for verifying it does and/or work to make it work.

[Stephan202]

Tnx! I happened to have sent you an email just over an hour ago with an attachment that contains some test cases that can be used for this purpose :)

[cowtowncoder]

@Stephan202 that definitely would! We can add them under src/test/java/..../failing to run manually & moved to other places after fixing.

[Stephan202]

Ack! I can modify the code I sent by mail and open a PR. Won't have time for that right now; but can do tonight/tomorrow. 👍

[cowtowncoder]

@Stephan202 that'll be awesome, whenever -- I probably won't have time to look into this particular issue immediately anyway. But will be good to have reproduction.

[Stephan202]

Alright, I filed #3111.

[cowtowncoder]

I think this was solved along with #3143 -- test now passes. Fix will be included in 2.13.0 (since it required bigger refactoring of things unfortunately, cannot safely backport).