This issue concerns the behaviour of the JMS provider when it sends a BytesMessage.
The spec is not clear on what state the body of a BytesMessage is left in after it has been sent. I'm talking about the message object in the sending program, not in the receiving program. There are three possibilities:
1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.
2. The JMS provider calls reset(). This leaves the BytesMessage in read-only with the stream positioned at the start.
3. Leave the behaviour undefined.
I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.
This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send() returns. In the async case the message is what state the message is in when the CompletionListener callback is performed. Let's consider these separately.
Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.
I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a CompletionListener callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to onCompletion() if its body is not readable?
Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.
JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.
In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a BytesMessage after it has been sent.
Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.