So, the proposals on this issue stand as follows:

1. A new method on Connection with no arguments as follows:

-----------------------------------------------------------------
Session createSession() throws JMSException

This method is particularly intended for use in a Java EE environment,
though it may also be used in a normal Java SE environment.

In a normal Java SE environmentm this is equivalent to calling createSession(Session.AUTO_ACKNOWLEDGE)

In a Java EE transaction, the session will be part of a transaction managed by the container.

In a Java EE undefined transaction context, the session will have a sessionMode of Session.AUTO_ACKNOWLEDGE.
-----------------------------------------------------------------

2. In addition, a new method on Connection with a single argument. There are two alternatives:

Option 2A (proposed by Nigel)
-----------------------------------------------------------------
Session createSession(int sessionMode) throws JMSException

In a normal Java SE environment sessionMode may be set to
Session.AUTO_ACKNOWLEDGE, Session.CLIENT_ACKNOWLEDGE, Session.DUPS_OK_ACKNOWLEDGE
or Session.TRANSACTED

In a Java EE transaction, sessionMode is ignored.

In a Java EE undefined transaction context, sessionMode may be set to
Session.AUTO_ACKNOWLEDGE or Session.DUPS_OK_ACKNOWLEDGE only.
-----------------------------------------------------------------

Option 2B (proposed by Ruediger and John)
-----------------------------------------------------------------
Session createSession(SessionMode sessionMode) throws JMSException

In a normal Java SE environment sessionMode may be set to
SessionMode.AUTO_ACKNOWLEDGE, SessionMode.CLIENT_ACKNOWLEDGE, SessionMode.DUPS_OK_ACKNOWLEDGE
or SessionMode.TRANSACTED

In a Java EE transaction, sessionMode is ignored.

In a Java EE undefined transaction context, sessionMode may be set to
SessionMode.AUTO_ACKNOWLEDGE or SessionMode.DUPS_OK_ACKNOWLEDGE only.
-----------------------------------------------------------------

3. The existing createSession with two arguments would remain unchanged


From the responses received so far, I think there is general consensus support for (1). However I do need views on
whether you prefer (2A) or (2B).

My own preference is for (2A). No doubt if the spec had been written subsequent to Java 5 it would have used enums.
However it wasn't and JMS has used these four integer constants for many years and people have been using them without
any problem. Introducing a set of enums to specify exactly the same thing as these existing constants simply adds
complication and potential confusion to solve a non-existent problem.

But please do give your views.

Nigel