Proposal: Automatic Resource Management (original) (raw)

Jeremy Manson jeremy.manson at gmail.com
Wed Mar 4 00:03:51 PST 2009

On Tue, Mar 3, 2009 at 11:56 PM, Neal Gafter <neal at gafter.com> wrote:

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.

That's why I suggested changing try() so that it took an expression. The second version was, I think you will admit, much cleaner.

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.

I'm probably being typically dumb, but I'm not sure how adding a method breaks anything. You don't have to change the signature of lock -- just add a new method (call it "disposeLock") that has the required semantics:

try (lock.readLock().disposeLock()) { clientCount++; }

try (lock.writeLock().disposeLock()) { return field.getValue(); }

Jeremy

More information about the coin-dev mailing list