Proposal: Automatic Resource Management (original) (raw)

Joshua Bloch jjb at google.com
Wed Mar 4 11:09:22 PST 2009

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

More information about the coin-dev mailing list