Support for Generics

[tanmoy.banerjee]

Is there any particular reason why

org.springframework.amqp.support.converter.MessageConvertor

is not

org.springframework.amqp.support.converter.MessageConverter<T>

with correspondingly changing the method signatures?

It will be great if the next fix version changes this.

[Mark Fisher]

Typically a MessageConverter is used in situations where *any* Object could be passed to it (e.g. when handling a return value from a method invoked by a MessageListenerContainer). That also means that it would not ever be truly type-safe when used in such situations anyways, so I'm not sure that parameterization adds much value.

Can you describe how you are using it, and why you think the parameterization is helpful?

Thanks,
Mark

[DRStevens]

I don't necessarily disagree with you, but in order to do this correctly, you would need to genericize much more than just the MessageConverter. Take the RabbitTemplate for instance. It would need to be defined as RabbitTemplate<T>, as the signature of setMessageConverter would need to change to

public void setMessageConverter(MessageConverter<T> messageConverter) {...}
...
public void convertAndSend(T object) throws AmqpException {...}

This means pretty drastic breaking changes.

The receiving side uses reflection anyways in order to identify the correct method on your handler to call. You still have no static type safety here. I suppose you could add a type param to MessageLIstenerAdapter so it takes a Handler<T> instead of object as well.

If you want to handle more than one message type, like most people do, you would need to have a common Iface or base type. You will still need to have a nasty nested if/else block with cast in multiple places (or less nasty pattern match in scala) in order to correctly deserialize and handle the different message types.