Please: try-with-resouces Lock support!

[Bruce Chapman]

On 26/02/2011 4:19 p.m., Howard Lovatt wrote:
> I haven't checked the specification, but on the latest JDK from the
> Mercurial repository:
>
>    try ( l.autoLock() ) { ... }
>
> Is fine,
>
>   -- Howard.
You re both right. Previous specs allowed an expression or a variable 
declaration but that is too hard (read impossible) to get to work right 
with 1 lookahead. Joe's blog has some examples. Therefore the expression 
form has been removed from the spec by the expert group, the code base 
is probably lagging a little behind which is why it works (for now).

Bruce


> On 26 February 2011 13:18, David Holmes<David.Holmes at oracle.com>  wrote:
>> Howard,
>>
>> The t-w-r needs a resource declaration, so as per my example you'd still
>> need to do:
>>
>> try ( Lock l2 = l.autolock()) { ... }
>>
>> Using defenders to retrofit AutoCloseable to Lock does make it simpler to
>> implement.
>>
>> However there's still additional overhead here and I wouldn't vote for this.
>>
>> David
>>
>> Howard Lovatt said the following on 02/26/11 10:40:
>>> The use case:
>>>
>>> try ( new ReentrantLock() ) { ... }
>>>
>>> makes no sense, you *need* to share the lock. However if Lock were
>>> modified to use defender methods:
>>>
>>> interface Lock extends AutoCloseable {
>>>
>>>   ... // As before
>>>
>>>   Lock autoLock()  default Trait.autoLock;
>>>
>>>   // Similarly autoLockInterruptibly
>>>
>>>   void close() default Trait.close;
>>>
>>>   static final class Trait {
>>>     public Lock autoLock(final Lock self) {
>>>       self.lock();
>>>       return self;
>>>     }
>>>
>>>     // Similarly autoLockInterruptibly
>>>
>>>     public void close(final Lock self) {
>>>       self.unlock();
>>>     }
>>>   }
>>> }
>>>
>>> Then
>>>
>>> try (l.autoLock()) { ... }
>>>
>>> would work.
>>>
>>>   -- Howard.
>>>
>>> On 24 February 2011 11:42, David Holmes<David.Holmes at oracle.com>  wrote:
>>>> I suspect Joe will shut this down as being out of scope for coin-dev in
>>>> its present state, but my 2c
>>>>
>>>> Gernot Neppert said the following on 02/24/11 03:31:
>>>>> this has been discussed here before, but somehow got lost:
>>>>> Wouldn't it be very handy having a class
>>>>> "java.util.concurrent.AutoLockable" that could be used as follows:
>>>> No not really. The way try-with-resources has evolved really doesn't
>>>> mesh with lock usage. As Neal already mentioned the overhead of creating
>>>> the AutoLockable per lock operation is simply prohibitive. Even if you
>>>> retrofitted Lock with AutoCloseable you would still need (given t-w-r
>>>> synatx) to have a helper method to acquire the lock and return it so you
>>>> can assign it to the local:
>>>>
>>>>   try ( Lock l = Lock.lockAndReturn(lock) ) {
>>>>   ...
>>>>   }
>>>>
>>>> This is just a round-hole vs square-peg situation, and trying to make it
>>>> fit really doesn't add anything to clarity or useability in my view.
>>>>
>>>> I can imagine a more general (more specific?) t-w-r that might allow:
>>>>
>>>> try (lock) {
>>>>    ...
>>>> }
>>>>
>>>> but that would be for future debate.
>>>>
>>>> Cheers,
>>>> David Holmes
>>>>
>>>>> try(AutoLockable locked = AutoLockable.locked(lock))
>>>>> {
>>>>> // Do something in locked scope
>>>>> }
>>>>>
>>>>> It would look something like this:
>>>>>
>>>>> package java.util.concurrent.locks;
>>>>>
>>>>> public abstract class AutoLockable implements AutoCloseable {
>>>>>
>>>>>      public static AutoLockable locked(final Lock lock)
>>>>>      {
>>>>>          lock.lock();
>>>>>          return new AutoLockable() {
>>>>>
>>>>>              @Override
>>>>>              public void close() {
>>>>>                  lock.unlock();
>>>>>              }
>>>>>          };
>>>>>      }
>>>>>
>>>>>      public abstract void close();
>>>>> }
>>>>>
>>>>>
>>>
>>>
>
>