Proposal: Automatic Resource Management

Reinier Zwitserloot reinier at
Thu Mar 5 07:18:00 PST 2009

I like the 'finally' keyword idea, but I don't think its neccessarily  
a good idea to call such classes 'Resources'.

Is a lock a resource? (Talking about the general concept here, not any  
particular implementation). Not sure if that's the right term. It is  
feasibly something that would have a finally method? Absolutely.

Micro-benchmarking is bad, but theoretically, if you wanted to, you  
could use an ARM-style block to do the job. That's definitely not a  
resource, and not neccessarily a bright idea, but I hope it gets the  
point across:

The notion of being able to create an object, where that object gets  
notified if the thread exits the block, no matter how it does so, is  
sufficiently useful that it will be used by things that aren't  
neccessarily a 'Resource'.

Then again, javadoc should definitely explain that you can use an  
instance of a class in a guarded block like that, and it'll need some  
sort of convenient term. "Guarded" is all I can come up with, which  
doesn't really sound right either. There's an established tradition in  
the programming world of terms taking on their own meaning. (After  
all, isn't "static" suggestive of 'constant', even though it has  
nothing to do with that? The term has been internalized as jargon).

  --Reinier Zwitserloot

On Mar 5, 2009, at 00:17, Joshua Bloch wrote:

> Tim,
> Hi!
> On Wed, Mar 4, 2009 at 2:40 PM, Tim Peierls <tim at> wrote:
>> I've never understood the fervor with which Java is defended from
>> annotations that can change program semantics; the defenders'  
>> arguments
>> always sound suspiciously circular. But never mind that ... I  
>> confess that
>> even though I would have been happy with
>>    @Finally public void release() { ... }
>> I'd much prefer
>>    public finally void release() { ... }
> I think it's worth adding this to the proposal as a design  
> alternative.  The
> finally modifier could appear on one and only one method.  It would  
> have to
> be a public, parameterless instance method.  This would require a  
> (small)
> class file format change, and a change to the JavaDoc tool, which  
> would
> document that the class was a "resource," and which method was its  
> disposal
> method.  It would make the automatic resource management statement a  
> bit
> more broadly applicable at the expense of a bit of added complexity.
>          Josh

More information about the coin-dev mailing list