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