Proposal: Automatic Resource Management (original) (raw)

Joshua Bloch jjb at google.com
Wed Mar 4 00:12:53 PST 2009

A gentle reminder: this construct was designed for one thing and one thing only: resource management. It was not designed for locking. Java already contains a native construct for locking (synchronized). A very small minority of Java programmers use java.util.concurrent.atomic.Locks. Support for them is not a priority. Nearly all Java programmers use resources such as java.io.InputStream, OutputStream, Reader, Writer, Formatter; java.nio.Channel; java.net.socket; java.sql.Connection, Statement, ResultSet, or java.awt.Graphics. That's what this construct is designed for. Goodnight,

Josh

On Wed, Mar 4, 2009 at 12:03 AM, Jeremy Manson <jeremy.manson at gmail.com>wrote:

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