On 16/12/2011 17:10, Nigel Deakin wrote:
> 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...
OK, I've now done that and updated the javadocs and draft spec accordingly. That's much better.
Nigel
>
> 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
>>