Philippe,
(Sorry for long delay in replying. Holidays, etc)
On 26/12/2013 10:02, Philippe Marschall wrote:
> Hi
>
> Since it's time to gather ideas for JMS 2.1 I thought I'd mention this eary. I noted that #getBody does not have any
> conversions defined for StreamMessage. IMHO it would be really convenient if the following conversions where offered:
>
> - java.io.InputStream (if the message is not in write-only mode)
> - java.io.OutputStream (if the message is not in read-only mode)
> - java.io.Reader (if the message is not in write-only mode)
> - java.io.Writer (if the message is not in read-only mode)
>
> This would also make it very easy to plug StreamMessage into anything else that does stream oriented IO in Java.
>
> Obviously #isBodyAssignableTo(Class) would have to be updated as well.
Thanks for the suggestion. Yes, this is definitely worth a discussion. I've logged it as
https://java.net/jira/browse/JMS_SPEC-144
I think the main thing we need to consider is whether such a feature ends up making the API simpler or more complicated.
We're not making any decisions right now, but I'm happy to discuss this now or on the JIRA issue. This needs careful
consideration, but here are some of the issues which come to mind and which need to be considered:
This proposal doesn't simply provide a simpler alternative to existing API, it adds new functionality to StreamMessage.
StreamMessage doesn't currently have methods to return objects of any of these four types, so the first thing to
consider is whether we would want to add four new methods to StreamMessage to return an InputStream, OutputStream,
Reader and Writer.
The StreamMessage object has methods which make it look like a stream, but it doesn't actually have any methods to
return the stream directly. This was probably deliberate as it didn't force the implementer to use a stream internally.
We need to consider carefully whether exposing the underlying stream (or perhaps forcing the implementation to create
one if it doesn't use one internally) might cause problems for implementers.
The classes Reader and Writer are for character streams only, whereas a StreamMessage can hold a stream of different
object types. I'm not sure that's a good match.
As for InputStream or OutputStream: I wonder whether returning an ObjectInputStream or ObjectOutputStream would be more
appropriate, since these stream types, like StreamMessage, have specific methods to read and write various primtives
such as Boolean or Long rather than simply bytes. However the methods it allows are not identical to the methods on
StreamMessage (e.g. StreamMessage defines its own rules on type conversion). I wonder whether the differences would
cause difficulties.
You use the word "conversions". Currently #getBody doesn't perform type conversions. There is currently a one-to-one
mapping between the message type and the class that must be passed in. For example you can't use call
getBody(byte[].class) on a TextMessage to obtain the text string as an array of bytes. But if we allow the body of a
StreamMessage to be returned as (say) a OutputStream, do we also need to allow the same for other message types such as
BytesMessage or TextMessage?
Nigel