Proposal: Automatic Resource Management

[Stephen Colebourne]

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