Proposal: Automatic Resource Management

[Jeremy Manson]

Neal said he thought the cure was worse than the disease with that
approach when I pointed it out earlier in the thread (I called the
class LockDisposer, FWIW).  I believe he was probably referring to the
verbosity and the extra objects.

The "right" fix, if we want to support this pattern, is to allow the
try resource statement to accept expressions that return Disposables,
and to retrofit the relevant lock APIs with disposables and lock
methods that return this:

class Lock implements Disposable {
  public Lock dlock() {
    return this;
  }
  @Override public void dispose() {
    unlock();
  }
}

Then, for Lock lock, you can just say:

try (lock.lock()) {
  // ...
}

Which is much cleaner.

Jeremy


On Sat, Mar 7, 2009 at 2:02 AM, Xavi Miró <xmirog at gmail.com> wrote:
> Neal,
>
>   this proposal tries to achieve big benefits with small changes. In my
> opinion, Streams, Readers, Writers, Formatters, Channels, Sockets,
> Connections, Statements, ResultSets, or java.awt.Graphics are much more
> used than Locks. This does not mean that Locks are not important. If the
> proposal can be applied to the formers it will be a huge benefit,
> although Locks can't be used directly with it.
>
>   I agree with Bob, adapters can be used for many use cases where
> "close" methods are incompatible with the Disposable or Resource
> interface. And although the proposal is not designed to manage Locks,
> perhaps a kind of "safe unlocker" can be easily made, so this original code:
>
>     myLock.lock();
>     try {
>         // access the resource protected by myLock
>     } finally {
>         myLock.unlock();
>     }
>
> could be written this way:
>
>     try (SafeUnlocker = new SafeUnlocker(myLock)) {
>         // access the resource protected by myLock
>     }
>
> where SafeUnlocker would be more or less like this:
>
> public class SafeUnlocker implements Disposable {
>
>  private final Lock lock;
>
>  public SafeUnlocker(Lock lock){
>    this.lock = lock;
>    lock.lock();
>  }
>
>  public void close throws Exception {
>    lock.unlock();
>  }
> }
>
> The name SafeUnlocker maybe it's not appropriate, but I haven't found a
> better one. There can be problems in this source code that I haven't
> seen...this is only an idea.
>
>  Regards,
>
>      Xavi
>
> Neal Gafter escribió:
>> On Fri, Mar 6, 2009 at 4:02 PM, Bob Lee <crazybob at crazybob.org> wrote:
>>
>>> On Fri, Mar 6, 2009 at 3:19 PM, Neal Gafter <neal at gafter.com> wrote:
>>>
>>>> If you've already decided which resource-like APIs "count", then you
>>>> don't need to ask us.
>>>>
>>> Did I unfairly discount some APIs? If so, please speak up.
>>>
>>
>> I did, and you quoted me just after asking the question (see below,
>> for example).  Apparently, because some other use cases are more
>> problematic, you feel that the ones I brought up are unimportant.
>> I've certainly run into situations where automatic pairing of resource
>> acquisition and release for java.util.concurrent locks would have
>> avoided errors.  I know that supporting resource acquisition and
>> release for all the different resource APIs that exist (or will exist)
>> in Java is difficult to do apriori in a language change (which is why
>> I prefer an API-based solution), but pretending the use cases don't
>> exist seems dishonest.
>>
>>
>>>> Personally, I'd like java.util.locks.Lock to be
>>>> easier to use, though I understand this proposal doesn't solve that
>
>
>