users@jms-spec.java.net

[jms-spec users] [jsr343-experts] Re: Make Connection, Session and other interfaces implement AutoCodeable

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Fri, 16 Dec 2011 17:10:17 +0000

On 16/12/2011 14:30, Rüdiger zu Dohna wrote:
> IIRC an interface can actually extend multiple interfaces. So also the Session should be able to extend AutoCloseable and Runnable.

I'd rather hoped I was doing something wrong, and it appears I was. The following does compile:
    public interface Session extends Runnable, AutoCloseable {
I must have been trying something different.

This means I'll add AutoCloseable to the other interfaces...

Thanks,

Nigel

>
> On 2011-12-16, at 13:48, Nigel Deakin wrote:
>
>> On 15/12/2011 18:27, Nigel Deakin wrote:
>>> On 29/09/2011 15: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.
>>>
>>> This proposal received support and no objections when I raised it some time ago.
>>>
>>> I've been looking at this in a bit more detail.
>>>
>>> Making Connection, MessageConsumer, MessageProducer, QueueBrowser extend AutoCloseable seems straightforward.
>>>
>>> However there's a problem with Session. This already extends Runnable, so I can't make it extend AutoCloseable. (I can't
>>> think of an obvious way around this, but if I've missed something obvious please let me know)
>>>
>>> This suggests two options:
>>>
>>> 1. Leave Session unchanged and make all the other interfaces extend AutoCloseable
>>>
>>> 2. Option (1) is confusing and inconsistent to users. It's better to simply make Connection extend AutoCloseable and
>>> leave the other interfaces unchanged. In practice the only object that actually needs closing in practice is COnnection
>>> anyway.
>>>
>>> Any preferences? I'm inclined towards (2)...
>>
>> I've now updated the javadocs and the draft spec with details of this new feature (these changes are additive, so those
>> docs include other changes).
>>
>> The updated Javadocs are here:
>> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/target/jms-2.0-javadoc.jar
>> (See the small change to Connection)
>>
>> The updated draft spec is here:
>> http://java.net/projects/jms-spec/sources/repository/content/jms2.0/specification/word/JMS20.pdf
>> (all changes are highlighted clearly with changebars, but the only place I've changed is 4.3.5 "Closing a Connection",
>> the example in section 9.1.3. Creating a Connection", and section 11.5.3 "Automatically closing a connection", which is
>> just a change log)
>>
>> I've only made Connection extend AutoCloseable. As mentioned above, I couldn't change Session since this already extends
>> Runnable. Although I could have changed MessageProducer, MessageConsumer and QueueBrowser I decided to leave these
>> unchanged since I thought it better to have Connection as the special case which does support try-with-resources (since
>> this is the only object that actually needs closing) rather than have Session as the special case which does not. (Note
>> that MessagingContext, part of the proposed simplified API, already extends AutoCloseable)
>>
>> Nigel
>