Design question

[whyBish]

Why is MessageHandler:
Message<?> handle(Message<?> message);
and not
<T> Message<T> handle(Message<T> message);
?

[amsmota]

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?

Nevertheless, in this paper from Sun, it reads:

(...) 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.

[whyBish]

Isn't the current way saying that the incoming type of the payload can be different to the outgoing type of the payload? Is this intended?

[Mark Fisher]

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:

Message<SomeDomainObject> handle(Message<String> someXml) {...}

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.

Thanks,
Mark

[whyBish]

Thanks for that.

[amsmota]

That *is* intuitive for me, as from my first experiences on a RESTless web service I always have worked with something like

Message<ResponseBean> handle(Message<RequestBean> rb) {...}

and actually I never thought of it otherwise...