+1
On 29.09.2011 16:24, Nigel Deakin 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
>
> 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
>
>
>