Proposal: Automatic Resource Management

[Joshua Bloch]

It is perhaps worth reiterating that the "finally" (or other keyword)
solution really does make things more complex.  We'd need to add rules like
this: A class is a resource iff it has a method that is labeled finally.
 The superclass of a resource must not be a resource.  The finally modifier
must not be used on an interface 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. 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";)
           Josh

On Wed, Mar 4, 2009 at 3:54 PM, Stephen Colebourne <scolebourne at joda.org>wrote:

>  > interface Disposable {
>  >      void close() throws Exception;
>  > }
>  > interface Destroyable {
>  >      void dispose() throws Exception;
>  > }
>  > interface Kloseable {
>  >      void destroy() throws Exception;
>  > }
>
> Er, no. If its to be an interface it needs to be just one.
>
> A single interface - Disposable defining close() covers most use cases,
> and API writers would adapt in the future.
>
> > public finally void release() { ... }
>
> I think this works well, and opens up more options. Are there any
> specific grammer objections?
>
> It would be possible to add a marker interface Finally which enforces
> the presence of the finally modifier, but that seems to have little
> obvious benefit, and be a bit magical.
>
> Stephen
>
>