Proposal: Automatic Resource Management

[Joshua Bloch]

Mark,

Thanks.  Actually I'm impressed that you, Tim, Bob, Reinier, Stephen and I
can all agree on this in the span of an hour:)

   Josh

On Mon, Mar 9, 2009 at 11:18 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

> I fear the question will come up again, but +1 from me if it allows the
> proposal to move forward.
> Best regards,
>
> Mark
>
>
> 2009/3/9 Tim Peierls <tim at peierls.net>
>
> > 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
> > >
> > >
> >
> >
>
>