Describe your Issue

SerializationContext contains a series of find*Serializer methods, all of which return ValueSerializer<Object>. It would be much more convenient and type-safe if they admitted a generic type parameter. For instance:

public <V> ValueSerializer<V> findValueSerializer(Class<V> type)

Comment From: cowtowncoder

Based on my experiences with Jackson versions up to 2.19, adding type parameters in these specific cases is counter-productive, adding unnecessary casts on caller end, while providing little benefit to anyone. Almost all internal databind code will just need to case nominal type down to Object.

Comment From: jafarre-bi

It's difficult for me to imagine the problematic use cases you mention, as this is a typical method definition with generics, which takes the actual type parameter from the Class instance passed to the method, and no casts are necessary.

I decided to write this issue when I encountered an issue casting from ValueSerializer to ValueSerializer, because the compiler considered this cast illegal. In my personal experience, all the problems with generics come from points in the code where they weren't used properly. I'm sure many people feel tempted to use raw types systematically, but my opinion is that proper use of generics allows you to detect issues at compile time that would be very difficult to track down when you find an unexpected ClassCastException at runtime.

And after all, what's the point of having a parameterised ValueSerializer class, if we are always going to use it as ValueSerializer? You may as well completely remove the type parameter from the class, and it would save confusion.

Comment From: cowtowncoder

From inside of jackson-databind, actual generic type is mostly impediment, not an asset. It is very different from that of using it from client side. This because type is always determined dynamically with reflection and not available from source -- hence type erasure is a problem.

There are places inside, too, where generics can be convenient (from within ValueSerializer itself, plausibly), but for majority of handling ugly casts are needed due to dynamic typing needed.

And you are right, having type parameter for ValueSerializer is something that should probably have been removed for Jackson 3.0: I agree its value is questionable, maybe negative (and same for ValueDeserializer). Defining things as ValueSerializer<Object> is useless indeed.

Comment From: jafarre-bi

I'm sure you have already thought about all possible solutions, but I can't help thinking. Couldn't something like this help in those cases? public <V> ValueSerializer<? super V> findValueSerializer(Class<V> type) Or perhaps public <V> ValueSerializer<V> findValueSerializer(Class<? extends V> type) But my intuition tells me that the first one may fit your use cases better. Hoping my ideas may be of help :)

Comment From: cowtowncoder

I do not see an actual problem to solve here, sorry.

.