Proposal: Automatic Resource Management

[Neal Gafter]

On Tue, Mar 3, 2009 at 11:49 PM, Jeremy Manson <jeremy.manson at gmail.com> wrote:
> As a side note to this conversation, directed at any people who will
> think you can't have this feature with this proposal, regardless of
> your feelings about the particular merits of accomplishing the same
> thing with closures, there *is* a way to handle this case:
>
> try (LockDisposer l = new LockDisposer(lock.readLock())) {
>  clientCount++;
> }
>
> try (LockDisposer l = new LockDisposer(lock.writeLock())) {
>  return field.getValue();
> }

Yow.  I think the cure might be worse than the disease.

> I suspect a LOT of people will be doing something similar to this hack
> if this proposal is adopted.  To make it much cleaner, you could first
> adjust this proposal so that the try statement can take an expression
> that returns a Disposable, and then you could adjust the Lock classes
> so that a) lock() returns this and b) they implement Disposable, at
> which point you could have:

You can't make such changes to existing interfaces without breaking
existing code.  Changing the signature of lock() breaks existing
callers, and adding a close() method (to implement Disposable) breaks
existing implementations.