Given some knowledge about the implementation I am not exactly "surprised" - and only looking at the method signature I could even follow your interpretation. With this in mind it is more a "surprise" that getDataAsObject still works... And it is a "surprise" that older versions work as we expect...

What I don't understand is why this optimization (narrowing down the possible value extractors) is already done based on the return value. For the validation itself the implementation still has to invoke the method just because of the @Valid annotation, correct? So why not narrowing things down AFTER the call based upon the return value?

And finally I just digged up the spec and found this part (5.1.3. Graph validation): "The exact type Z of the value contained in the field declared of type Y (subclass, implementation) is determined at runtime." The spec here refers to the constraints to apply on a value, but I tend to see no difference here to Set/List/Array/Map-handling? Without this "determine types at runtime" rule I would not even expect the getDataAsObject example to work at all...