I think that approach deviates from the spec in a similar sort of
subtle way the use of MapMessage does, i.e. you can't send any
Serializable object in the map or list.
I do accept it provides quite a nice and consistent interface provided
you can explicitly control the encoding to use when sending.
It's an interesting conversation piece. I don't know about the
specification document per se, but that JavaDoc for ObjectMessage says:
"An |ObjectMessage| object is used to send a message that contains a
serializable object in the Java programming language ("Java object")".
Being pedantic :-) it says *a* serializable object not *any*
serializable object, so I could argue that a Map containing any type
that has a defined AMQP mapping to Java is also serializable, so does
actually conform to the spec (unless there's something formal that
actually does say *any* serializable Object).
Of course I'm now just being facetious :-) I completely agree with the
"provided you can explicitly control the encoding " I think ultimately
that's the bit that's currently missing from the Java bindings, as we've
already discussed. I think that it's good to have these conversations I
find them really interesting (how sad am I). It's fascinating to get the
perspective of others around interpretations of specifications etc. .
I'm not violently opposed to "Being able to treat it as some other
message type may also be reasonable. " and I know from our conversations
wrt. Proton that you've got some views with respect to providing choice.
That's kind of fair, though my *personal* view is that it's ultimately a
good idea to provide consistency and encourage common design patterns.
Yes, choice can be good but it can sometimes by unnecessary and
confusing. In this particular case my view is that if an application
is able to handle one of the message types and you could expose the
data to them in a way that makes sense, why not do so.
That's fair enough <facetious>providing that it doesn't break code that
was using the previous interface</facetious>
Fortunately none of this wound up being too big a deal for me as I'd
already abstracted my Map and List handling into a helper class because
a) I hate working with MapMessage (did I mention that :-)) and b) I had
a hunch that List support may change and I also wanted to hide the low
level encoding/decoding to BytesMessage. So it was easy enough to add an
extra test for MapMessage in my code for amqp/list. In the latest
release I've also added some extra abstractions for testing for
amqp/list and amqp/map because I'm currently down-casting to the
underlying Qpid Message to do getContentType() which is a bit ugly and
could break in some future Qpid release.
I was quite relieved that *encoding* amqp/list via BytesMessage was
still supported. That would have been a lot more of a pain than decoding
'cause I can defensively code for the decode, but not for the encode so
that would have required specific code changes for pre 0.20 and 0.20 on,
fortunately that's not the case so the single code base should work
across all versions now.
Thanks for all your thoughts on this, it's always fun to chat around
this stuff.
Frase
