I thought I had this listed in my goals. Yes, this is something we should
do.
On Thu, Sep 29, 2011 at 10:24 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> I'd like to raise this as a discussion topic rather than a concrete
> proposal.
>
> I've also logged this in JIRA
> http://java.net/jira/browse/**JMS_SPEC-53<http://java.net/jira/browse/JMS_SPEC-53>
>
> My question is: should we change all the JMS interfaces that currently
> implement a close() method to implement the java.lang.AutoCloseable
> interface?
>
> This would affect Connection, Session, MessageConsumer, MessageProducer,
> QueueBrowser.
>
> For those not familiar with it, this is a new feature of Java SE 7 which
> makes it easier to write code which closes a resource after use.
>
> There's a nice explanation here:
> http://www.javacodegeeks.com/**2011/07/java-7-try-with-**
> resources-explained.html<http://www.javacodegeeks.com/2011/07/java-7-try-with-resources-explained.html>
>
> Briefly, it allows you to write code such as:
>
> try {
> Connection conn = connectionFactory.**createConnection();
> Session sess = conn.createSession(false,**
> Session.AUTO_ACKNOWLEDGE;
> MessageProducer producer = seession.createProducer(dest);
> }{
> Message mess = sess.createTextMessage("hello"**);
> producer.send(mess);
> } catch(JMSException e){
> // exception handling
> }
>
> When this code is executed, the close() methods on the connection, session
> and producer are always called after use.
>
> * There's no need to call close() on any of the objects that are created.
> * There's no need to provide a finally() block containing the calls to
> close().
> * Objects are closed in the reverse order in which they were created.
> * There's no need to guard against calling close() on a null value.
> * There's no need to use a nested try/catch block within the finally block
> to catch exceptions thrown by close()
> * If the try() block throws an exception, and a subsequent call to close()
> throws a second exception as a consequence, then it is the first exception,
> not the second exception, that is passed to the catch block. So you only see
> the exception that really matters. Any suppressed exceptions can still be
> accessed from the thrown exception if needed.
>
> This change would be of benefit to both Java SE and Java EE applications.
> The only drawback I can think of is that it would introduce a dependency on
> Java SE 7. This isn't an issue for Java EE 7 applications since these are
> already dependent on Java SE 7. But it would force Java SE applications to
> use Java SE 7. However by the time JMS 2.0 is released, in a year from now,
> Java 7 will be pretty widespread so this might not be a problem.
>
> Comments?
>
> Nigel
>
>