Proposal: Automatic Resource Management

[Mark Mahieu]

Josh,

Yeah, sorry that email was a bit rubbish.  It was 3:30am though -  
please allow me to try again...

As you know some resources are allocated and held for much longer  
than the duration of a single method call, eventually being released  
on some trigger condition.  I'm not suggesting that ARM should try to  
cater for this, but I do see Neal's point that there's a common  
desire to pass such resources around or to hold them somewhere, and  
given that they are often the same *type* in both scenarios, then if  
ARM introduced the Disposable interface for its purposes, it would be  
natural for programmers to want to hold the more long-lived ones in a  
Collection<Disposable> for later disposal.

Now, where I was going with my last email was that a library could  
include an interface that extends Disposable, refining the exception  
types thrown:

interface SWTDisposable extends Disposable {
	void close() throws SWTException;
}

The afore-mentioned programmer could now hold a  
Collection<SWTDisposable> and have much more appropriate exception  
types to deal with in their cleanup code.  (SWTException is unchecked  
in real life, but the point's the same).

If that turned out to be a sensible convention, then the only  
responsibility for ARM would be to say, in the javadoc for  
Disposable, "libraries are encouraged to extend this interface,  
refining the thrown exceptions...".


Now, having mentioned SWT...

This fairly typical example, from the official SWT 'snippets' page,  
would benefit very well from the introduction of ARM or some other  
resource disposal mechanism:

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/ 
org/eclipse/swt/snippets/Snippet280.java?view=co


So if we look at how the SWT library might be retrofitted to work  
with ARM, we find this class, which is extended by all the various  
SWT resource classes:

public abstract class Resource {

	/**
  	 * Disposes of the operating system resources associated with this  
resource.
	 */
	void dispose() {
		// ...
	}

	// ...
}

http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/ 
reference/api/org/eclipse/swt/graphics/Resource.html


OK, well for once the SWT team's aversion to interfaces has an up- 
side, and we can easily retrofit this with Disposable, calling dispose 
() from close().  Or can we?

public class Path extends Resource {

	/**
	 * Closes the current sub path by adding to the receiver a line from  
the current point of the path back to the starting point of the sub  
path.
	 */
	public void close() {
		// ...
	}

	// ...
}

http://help.eclipse.org/stable/nftopic/org.eclipse.platform.doc.isv/ 
reference/api/org/eclipse/swt/graphics/Path.html


Square peg, round hole :(


Any suggestions?


Regards,

Mark



On 4 Mar 2009, at 03:47, Joshua Bloch wrote:

> Mark,
>
> I don't see a compelling need for it. When in doubt, leave it out.
>
>             Josh
>
> On Tue, Mar 3, 2009 at 7:39 PM, Mark Mahieu  
> <markmahieu at googlemail.com> wrote:
> So would APIs be encouraged to define more specific Resource
> interfaces that narrow the thrown exception types ...
>
> interface SQLResource extends Resource {
>        void dispose() throws SQLException { }
> }
>
> interface SWTResource extends Resource {
>        void dispose() throws SWTException { }
> }
>
> etc?
>
> I don't think there'd be any reason to do this.