Proposal: Automatic Resource Management

[Mark Mahieu]

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