Proposal: Automatic Resource Management

[Joshua Bloch]

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
>
>