John,
On 30/09/2011 11:46, John D. Ament wrote:
> 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.*.
Whilst that would indeed work, I don't see the benefit in adding this to the docs for a method that we're deprecating
anyway.
We don't want users to edit a call to
createSession(false,Session.AUTO_ACKNOWLEDGE) and replace it with a call to
createSession(false,SessionType.valueOf(Session.AUTO_ACKNOWLEDGE))
Instead we want them to replace it with a call to
createSession(SessionType.AUTO_ACKNOWLEDGE).
> 2. Recommend in the spec that implementations simply wrap this call as noted in the deprecated notes.
This would just be recommending a particular programming style in the implementation, so I don't think this is
necessary. Best to keep the spec free of hints on implementation unless they are really needed. Vendors can always look
at the RI for ideas.
>
> Are we also deprecating the Session constants? Are they used anywhere else in the API?
They're also used by Session.getAcknowledgeMode().
I should say that I'm still trying to find out from the Java EE spec leads and other platform experts the best practice
in respect of deprecating and removing methods, since the existing Java EE spec doesn't specifically comment about this
subject. I'll report back when I've received some guidance (e.g. whether we should do either).
Nigel
>
> John
>
> On Fri, Sep 30, 2011 at 4:45 AM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto: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
>
> (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
>
>
>
>
>