[JMS_SPEC-144] StreamMessage#getBody(Class<T>) Created: 23/Jan/14  Updated: 23/Jan/14

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jms21-forreview-minor

 Description   

Logged on behalf of Philippe Marschall, who posted this to the community alias:
https://java.net/projects/jms-spec/lists/users/archive/2013-12/message/16

Since it's time to gather ideas for JMS 2.1 I thought I'd mention this early. 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.



 Comments   
Comment by Nigel Deakin [ 23/Jan/14 ]

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 primitives 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?

Generated at Wed Aug 05 09:19:55 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.