[rabbitmq-discuss] Java RabbitMQ API bug in response.getHeaders()?

[Mario Leyton]

This is a nice discussion, though I want to remark that I am
specifically discussing the List/Map issues, not the single attributes.

The core of it I think is reduced into whether one would:

A. Want all client library (C, Java, Erlang, etc... ) to operate more or
less the same, or
B. Want all client library users to feel "at home" with the library's "API".

As a Java programmer, I don't really care if the library are used in
exactly the same way in C, Python or Erlang. I actually don't expect it.
For me it is very strange to have this semantic overload in the null
reference, which, as I mentioned in the previous post is actually very
annoying as  does not depend on the coding style but on the message
being sent and pollutes the user's code.

My feeling is that the rabbitmq teams is trying to aim for option A,
while for me, as a user of the java client library it is easier to adopt
rabbitmq client if it where built in terms of B.

Finally I just want to quote that I believe the RabbitMQ Team is doing a
good job and I'm happy to provide feedback as one of their users.

Mario Leyton
--
NIC Chile Research Labs
 
On 10/27/11 1:51 PM, Tony Garnock-Jones wrote:
> On 27 October 2011 12:23, Mario Leyton <mleyton at niclabs.cl> wrote:
>
>> If there are no headers, it doesn't matter why, a good API should always
>> return an empty Map o List and not null because it contaminates the API
>> user's code.
>
> It may do so for Java. Other languages do things like this differently.
> AMQP is language-neutral, and has its own semantics. The API should make it
> easy for the user to work with AMQP semantics, and should not, for example,
> lull the user into a false sense that all the world is a Java program. If a
> sender sent a message with a missing username header, for instance, that
> should be hard to misinterpret as the sender having sent a message with an
> empty-string username header. IMO, the same applies to maps, integers,
> booleans, timestamps etc. (I'm not even sure what a sensible
> "default"/"missing" value for a timestamp would be.)
>
> You're right that we could do what the C library does, and use a separate
> flag, but I believe this would make it more likely that subtle
> interoperability issues would arise. At least with the NPE you get rapid
> feedback that someone isn't following the communication contract; either
> the local Java code, in which case adding a null check lets you conform to
> the language being spoken by the remote party, or the remote party's code,
> in which case you can either choose to work around the difference locally
> or get the remote party to change. Papering over the difference at the API
> level masks the underlying problem.
>
> If you are working in an all-java environment, a good choice for your code
> might be to abstract away the difference between a missing map and an empty
> map.
>
> Regards,
>   Tony
>