John,
the constants are:
public static final int AUTO_ACKNOWLEDGE = 1;
public static final int CLIENT_ACKNOWLEDGE = 2;
public static final int DUPS_OK_ACKNOWLEDGE = 3;
public static final int SESSION_TRANSACTED = 0;
So it would match the enum:
public AcknowledgeType {
SESSION_TRANSACTED, AUTO_ACKNOWLEDGE, CLIENT_ACKNOWLEDGE,
DUPS_OK_ACKNOWLEDGE;
}
I understand, though, that ordinals should generally not be used to
transport semantics (cf. Effective Java, Item 31), but as this use is
deprecated _and_ was stable for 9 years, I'd say we are safe to ignore
that warning ;)
Rüdiger
On 27.09.2011 01:58, John D. Ament wrote:
> Rudiger,
>
> Perhaps, though not guaranteed. I would presume that each value in the
> enum set would have a numeric value matching the ordinal as defined in
> Session.
>
> John
>
> On Mon, Sep 26, 2011 at 10:30 AM, Rüdiger zu Dohna
> <ruediger.dohna_at_1und1.de <mailto:ruediger.dohna_at_1und1.de>> wrote:
>
> 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 <tel:26.09.2011%2011>: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>
> <mailto: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!
>
>
>