John,
the valueOf(int) method is a synonym for values()[i], isn't it?
And should we really declare this method:
> Connection.createSession(boolean,EnumClassName);
The "transacted" boolean is redundant to the EnumValue
SESSION_TRANSACTED, isn't it?
Rüdiger
On 26.09.2011 11:44, John D. Ament wrote:
> Thanks Rudiger for pushing this. I was trying to avoid "force" but
> figure I should pitch in; here's my attempt at clarifying my request,
> hopefully I don't mess it up :-)
>
> The way I see it, for backwards compatibility, we leave the int method
> in place:
>
> Connection.createSession(boolean,int);
>
> In the enum we introduce a valueOf method, taking the int value as an
> argument and returning the enum. We then add the following methods, and
> mark the current int method as deprecated:
>
> Connection.createSession(boolean,EnumClassName);
> Connection.createSession(); //for use in EE
> Connection.createSession(EnumClassName);
>
> We're not introducing four enums, we're introducing one enum that has 4
> values within it. The valueOf method helps us bridge the old way for
> calling and the new one. Here's how I figure each method would be used:
>
> Connection.createSession(boolean,int);
> just returns createSession(boolean, EnumClassName.valueOf(int));
>
> Connection.createSession();
> Just creates a default transacted session for EE use, with behavior in
> EE and SE as defined by Nigel below.
>
> Connection.createSession(EnumClassName);
> Transactional state as noted by Nigel above.
>
> Connection.createSession(boolean,EnumClassName);
> Same behavior as today.
>
> John
>
>
> On Mon, Sep 26, 2011 at 2:55 AM, Rüdiger zu Dohna
> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>> wrote:
>
> On 23.09.2011 16:34, Nigel Deakin wrote:
>
> ...further new method ... Session createSession()
> Any comments?
>
>
> Exquisit simplification... +1
>
>
> Separately, John suggested:
>
> Could your spec change perhaps use an enum to describe the
> sessionMode as well?
>
>
> If this has been a new API then an enum would have definitely
> been the right thing, and my initial reaction was to agree
> with John's proposal. However another EG member has pointed out
> that since we already have four static constants
> (Session.AUTO_ACKNOWLEDGE etc) adding four enum values which
> would effectively duplicate these would unnecessarily
> complicate the API. I'm therefore inclined to stick with the
> existing four static constants. Does anyone else have any
> particular views on this?
>
>
> I'd prefer the enum, too. The old constants could be marked as
> deprecated and eventually removed. All other methods that take such
> an int, would have to be marked as deprecated as well and get a new
> variant with the enum. I'm all for cleaning up APIs!
>
>