Consider removing "optimization" of handling Class<?> from TypeFactory.fromParamType

[kostislav]

I wanted to create a custom deserializer for Class<? extends Something> that would check the upper bound and throw an exception if it did not match. Easy enough, I thought, just a simple contextual deserializer.
But, the type kept coming in as a SimpleType without any generic arguments.

After some digging, I found that it is because of a special-case in TypeFactory.fromParamType that strips the generic arguments from Enum, Comparable and Class. While I agree that for the first two the type arguments aren't really useful, they sometimes would be for Class.

Please consider whether these "performance reasons" are worth the unintuitive (and possibly undocumented?) behavior.

Currently, the only way is to subclass TypeFactory to skip the special handling (but subclassing TypeFactory from another package is pretty painful thanks to its "mutant factory methods").

[cowtowncoder]

Hmmmh. I would be open to removing that specific case since compared to others it is less likely to actually improve performance (Comparable and Enum are commonly resolved and for some (possibly wasteful but still) use cases have measurable negative impact).

If you change this & run unit tests does the unit test suite still pass? I'd suspect it does.

Also: if you want, a PR against 2.14 would be well received (assuming tests pass as per above).
Although this seems like possibly low-risk change I have learned to be suspicious of "safe" changes that do not fix a bug and thus prefer this going in 2.14 to avoid any chance of 2.13 regression.

[cowtowncoder]

(labeling as "need-test-case" just as a reminder that changed behavior should be tested to avoid future regression etc -- not that I wouldn't believe behavior currently is as described).

[kostislav]

Great, thanks for the heads up! I'll run the change through the test suite and try to create a PR if no problems pop up.

[kostislav]

I created a PR, but I think I messed up somehow, sorry for that (first time doing a PR here on github) - it's at #3445

[cowtowncoder]

Fixed, to be included in 2.14.0.