Proposal: Automatic Resource Management (original) (raw)

Bob Lee crazybob at crazybob.org
Mon Mar 9 10:36:33 PDT 2009

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

More information about the coin-dev mailing list