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>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!
>