When we mark it as deprecated, I would recommend that we:
1. Mention use createSession(transacted,SessionType.valueOf(ackMode)); in
the deprecated note, or in the javadoc; instead of the current method. I
think this was what I was mentioning WRT ordinals and ordering, e.g. each
one would have an int value going back to Session.*.
2. Recommend in the spec that implementations simply wrap this call as noted
in the deprecated notes.
Are we also deprecating the Session constants? Are they used anywhere else
in the API?
John
On Fri, Sep 30, 2011 at 4:45 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> On 29/09/2011 20:14, Clebert Suconic wrote:
>
> (We're discussing createSession(transacted,**ackMode))
>
>
> I would rather deprecate it now. But no strong feelings about doing it
>> later.
>>
>
> Well, all three people who have expressed an opinion are in favour of
> deprecation. So let's deprecate it in the Early Draft and see what response
> we get during consultation. I've updated http://java.net/jira/browse/**
> JMS_SPEC-45 <http://java.net/jira/browse/JMS_SPEC-45>
>
> (More comments still welcome at this stage).
>
> When I proposed we deprecated the domain-specific interfaces in JMS_SPEC-47
> I also proposed making them optional in a future version of the API, in
> accordance with the general Java EE practice I described in that issue.
> However with this method, it doesn't make any sense to make it optional to
> implement a individual method so deprecation means that we propose
> physically deleting this method from a future version of the API. (Note
> that I haven't forgotten that we do need to have a proper discussion of our
> backwards compatibility goals - I have a half-written email on the topic
> which I need to finish)
>
> Nigel
>
>
>
>
>