Proposal: Automatic Resource Management

Mark Reinhold mr at
Wed Mar 4 19:35:41 PST 2009

> Date: Wed, 04 Mar 2009 16:37:41 -0800
> From: Joshua Bloch <jjb at>

> 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.  On the surface, at least,
doing this in the language makes a lot more sense to me than doing it
with an interface.  There are numerous subtleties, no doubt, but this
idea seems worth further investigation.

>						  We'd need to add rules like
> this: A class is a resource iff it has a method that is labeled finally.

That's not so hard.

>  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, or if it does
override it then it must declare that exact same method "finally".

>						         The finally modifier
> must not be used on an interface method.

Yes.  By analogy with "synchronized" one could say that "finally" just
doesn't belong in an interface.  This also avoids clashes in the case
of a class that implements two interfaces, each of which declares a
different disposal method.

>					    We'd need to decide which bit is
> to be set in the class file to indicate that a method has the finally
> modifier (luckily there are 6 available).  We'd need to decide whether a bit
> should be set on the resource class, and if so, which bit. It would be
> redundant to set such a bit, but it would allow the compiler and the VM to
> quickly determine whether a class was a resource.  We'd have to modify
> JavaDoc.

These are all perfectly valid concerns, but I don't think the answers are
necessarily all that hard.

>	   And so on. In the absence of this addition, the proposal really is
> a simple AST transformation. I'm not arguing that we shouldn't do
> the "finally" (or other keyword) thing, but that we should only do it if we
> decide that the added breadth of applicability is worth the added
> complexity.  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

- Mark

More information about the coin-dev mailing list