Proposal: Automatic Resource Management

[Joshua Bloch]

Mark,
Hello again.

On Wed, Mar 4, 2009 at 5:36 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

>
>
> 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).
>

Seems harmless.  This could also be be retrofitted: a class could implement
Disposable, and then be retrofitted to implement SWTDisposable in a later
release.  My natural inclination would be to do this only where there was a
clear need, and do it on a case-by-case basis as the need arose.


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

Yep.  This was bound to happen:(  That's why Tim Peierls favored the use of
an annotation to mark the "disposal method."  But Mark Reinhold has made it
clear that this would (still) be unacceptable to Sun: annotations must not
change semantics.  So be it.

This problem is one of those unfortunate things that happen when you
retrofit a feature after a platform has been around for over a decade:(  I
think the solution must necessarily be a bit hackish.  Here's one
possibility, based loosely on the way for-each works.  A resource can
implement one of several interfaces.  One (currently named Disposable)
contains a close method.  Another (name tbd) contains a dispose method.  A
third might contain a destroy method.  I can't imagine an existing type to
which none of these three interfaces can be retrofitted.  The SWT Resource
type could be retrofitted to implement the interface with the dispose
method, without even adding a new method. This isn't beautiful, but it
works.  I think it's probably a good idea.

    Thanks for all the sleuthing,

    Josh