This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
I'm not try to picking on you (seriously), but don't you think that if you're going to ask a question like that you should also tell us the "rationale" behind it, meaning the "why" you think it should be one way and not the other, or even if you are only confused about it?
(...) the type parameter T is used only once. The return type doesn't depend on the type parameter, nor does any other argument to the method (...). This tells us that the type argument is being used for polymorphism; its only effect is to allow a variety of actual argument types to be used at different invocation sites. If that is the case, one should use wildcards. Wildcards are designed to support flexible subtyping (...)
Generic methods allow type parameters to be used to express dependencies among the types of one or more arguments to a method and/or its return type. If there isn't such a dependency, a generic method should not be used.
I think, if I understood correctly, that this applies to your question too.
Yes, it is intended that a handler's outgoing payload might differ in type from the incoming payload. For example, a common requirement is to apply transformation of the data type and/or format... something like:
So, one option would be to provide MessageHandler<I,O> specifying Input and Output types. However, handlers might just as well handle and/or return multiple types of payload. For that reason, and the fact that handler implementations are largely "internal" (while developers typically use XML and/or annotations on methods to which MessageHandler adapters will delegate), the use of Message<?> seemed most appropriate. The reason that Message is parameterized itself, is that developers may interact with the Message objects more frequently.
Hopefully that description makes sense, but I'm definitely still interested in feedback (positive or negative). One of the main goals is to provide an intuitive API.