Proposal: Automatic Resource Management

[Tim Peierls]

CloseableResource is good, too. I have a mild preference for AutoCloseable,
because it leaves open the possibility of blessing other AutoXxx classes in
the future.
Maybe the name of the proposal is misleading, since not all resources can be
managed automatically, just those that have a void close() method.

--tim

On Mon, Mar 9, 2009 at 1:39 PM, Stephen Colebourne <scolebourne at joda.org>wrote:

> If I were naming, I'd call it CloseableResource, but thats just me ;-)
> Stephen
>
>
> 2009/3/9 Bob Lee <crazybob at crazybob.org>:
> > +1 on all counts. Thanks, Tim!
> >
> > Bob
> >
> > On Mon, Mar 9, 2009 at 9:26 AM, Tim Peierls <tim at peierls.net> wrote:
> >
> >> 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
> >> >
> >> >
> >>
> >>
> >
> >
>
>