Proposal: Automatic Resource Management

[Tim Peierls]

Attractive as the finally modifier seemed to me, I see the handwriting on
the wall. I'd like to get back to the core of the original proposal, which
still seems compelling and achievable: a small language change to make it
easy for users to avoid a common class of deadly mistakes. That's something
worth pursuing.

I really, really don't like the thought of having two "magic" interfaces,
Disposable and Resource. For one thing, we would have to deal with types
that extend/implement both Disposable *and* Resource by disallowing them in
ARM initialization. More importantly, there's historical precedent: At one
point during the JSR-201 discussions on for-each, the possibility of
allowing both Iterable and Iterator in the right-hand slot was seriously
considered but ultimately rejected. I think that was the right choice, and I
bet the majority of people on this list think so, too.

In addition, I don't like the names Disposable and Resource for two reasons:
(1) They are names that are already in use out there, Resource especially,
and even though there's no risk of ambiguity (they'd be in a package that
isn't automatically imported), it's impolite to promote these fairly generic
names for such a narrowly-targeted use. (2) They are not particularly good
names for things that are closeable, and "things that are tricky to close()
properly" is what motivated the whole ARM proposal.

I'd be happier with a less graceful but more accurate name that is less
likely to be in common use. For example:

public interface AutoCloseable {
    void close() throws Exception;
}

public interface Closeable extends AutoCloseable {
    void close() throws IOException;
}

(JBoss has an AutoCloseable, but it extends the standard Closeable, so that
works out OK.)

Yes, this forces the maintainers of resource-ish types that don't use
close() as the clean-up method to write adapters if they want their users to
take advantage of ARM. That's OK -- if getting the clean-up right is
sufficiently difficult and important, it will be worth adding those adapters
and documenting how to use them.

And yes, this will frustrate designers of new resource-ish types who want
ARM support but for whom "close" is not at all the appropriate verb. But
designers of new types are at least free to design abstractions that aren't
as delicate in their clean-up requirements as the current crop of
Closeables.

--tim


On Wed, Mar 4, 2009 at 11:54 PM, Joshua Bloch <jjb at google.com> wrote:

> Mark,
> Hi.
>
> On Wed, Mar 4, 2009 at 7:35 PM, Mark Reinhold <mr at sun.com> wrote:
>
> > > Date: Wed, 04 Mar 2009 16:37:41 -0800
> > > From: Joshua Bloch <jjb at google.com>
> >
> > > It is perhaps worth reiterating that the "finally" (or other keyword)
> > > solution really does make things more complex.
> >
> > Yes, but the complexity might be worthwhile.
>
>
> Agreed.  I wasn't saying that we shouldn't do it; just that we should only
> do it with our eyes open.
>
>
> >  On the surface, at least,
> > doing this in the language makes a lot more sense to me than doing it
> > with an interface.
>
>
> On the one hand, we did for-each with an interface.  But on the other that
> was targeted at a more limited set of types, and it was no real hardship
> that the method that they had to implement Iterable.
>
> >
> > >  The superclass of a resource must not be a resource.
> >
> > Not clear.  We could, e.g., allow a superclass to be a resource so long
> > as the subclass does not override the disposal method,
>
>
> Yep.  That's what I meant to say, but now what I said.  Oops;)
>
> >
> > >  Remember that Coin means "small change";)
> >
> > Indeed.  Joe might disagree, but to my eye a worked-out proposal for
> > keyword-based disposal methods could still meet the threshold of "small
> > change".
>
>
> Well, I'm happy to work it out.  Then we'll have two alternatives to
> compare.
>
>        Regards,
>
>        Josh
>
>