Implement #5064 (automatic type detection)

[rohanlopes20]

Create new PR based on @cowtowncoder comments

#5064 (comment)

[yawkat]

i havent followed the discussion, i dont know whether the name is settled yet, and i dont feel strongly about it, but how about 'readAutomatic' instead? it makes it clear that additional magic is happening, 'automatic' is similar to C++ auto, and it is still short enough to not be cumbersome.

[rohanlopes20]

i havent followed the discussion, i dont know whether the name is settled yet, and i dont feel strongly about it, but how about 'readAutomatic' instead? it makes it clear that additional magic is happening, 'automatic' is similar to C++ auto, and it is still short enough to not be cumbersome.

@cowtowncoder can you suggest.

[cowtowncoder]

I'll have to think about this: I do not think readObject() works.

My initial thinking is/was that we would just have a method for resolving type to create ObjectReader; but I am not sure what would be good name for that method.

Maybe ObjectReader forAutomaticType(...) or forDetectedType(...)?

[rohanlopes20]

I'll have to think about this: I do not think readObject() works.

My initial thinking is/was that we would just have a method for resolving type to create ObjectReader; but I am not sure what would be good name for that method.

Maybe ObjectReader forAutomaticType(...) or forDetectedType(...)?

Something like this ? @cowtowncoder. Also, are we going to remove method added for readObject?

    public <T> ObjectReader forAutomaticType(T... reified) {
        Type type = getClassOf(reified);
        _assertNotNull("type", type);
        return _newReader(deserializationConfig(), _typeFactory.constructType(type), null,
                null, _injectableValues);
    }

and test

        final String JSON = "[1]";
        JsonParser p = MAPPER.createParser(JSON);
        Object ob = MAPPER.forAutomaticType()
                .readValue(p);
        p.close();
        assertTrue(ob instanceof List<?>);

[cowtowncoder]

Yes, remove readObject(). And test should probably use target types other than java.lang.Object (although that can also be used) to ensure actual type introspection -- Object is "untyped" target, which maps JSON array as List anyway.

[cowtowncoder]

@rohanlopes20 just realized something: trying to make ObjectReader readerForAutomatic() (or similar) probably cannot work as there isn't actual type information included -- ObjectReader is not generic (unlike result value for ObjectMapper.readValue()).

I am not sure how to go about that, then -- I do NOT like either overloading dozens of readValue() methods, nor adding dozens of differently named ones. Nor changing signatures of readValue.

So not sure how to proceeed.

The only thing I can think of is to use this trick on creating JavaType maybe. But... would that be any less code from caller than just passing type (class) or TypeReference? (probably not).

EDIT: or maybe it does work? Test would need to use a POJO type, for sure.

EDIT/2: test I added shows it fails the way I originally feared: no type info passed since ObjectReader is non-generic. But maybe it could be changed... hmmm.

[cowtowncoder]

Instead of (or in addition to), really needs to use POJO type, to ensure type capture works.

[cowtowncoder]

... which, alas, proves failure. :-(

[cowtowncoder]

Wrong location, should be next to other factory methods; I'll move.

[cowtowncoder]

Also need name to align with readerFor() somehow

EDIT: chose readerForDetectedType()

[cowtowncoder]

Ok; edited PR to show how things fail with naive approach.

Not sure there is a way to fix this.

[rohanlopes20]

Ok; edited PR to show how things fail with naive approach.

Not sure there is a way to fix this.

It indeed fails :(. Let me check if any other way possible or not. Currently MAPPER.readerForDetectedType().readValue fails to detect Point class as ObjectReader is not generic.