Announcement Announcement Module
No announcement yet.
Support for Generics Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Support for Generics

    Is there any particular reason why
    is not
    with correspondingly changing the method signatures?

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

  • #2
    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?



    • #3
      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.