Proposal: Automatic Resource Management

[Sean R. Drucker]

I didn't consider retrofitting.

Two options come to mind:

1.  Move the for-each for disposable iterators to the new try syntax:

try (Row row: table) {
}

In addition to table.iterator() being disposed, if Row implements 
Disposable, then each row would be disposed after each iteration.  The 
variable table would not be disposed unless the following syntax is used:

try (Table table = new Table("Ex"); Row row: table) {
}


2.  Add a DisposableIterator (or similar) interface:

interface DisposableIterator<E, X extends Throwable>
   extends Iterator<E>, Disposable<X> {
}

The implementation of Iterable.iterator() would need to be a static 
class that extends DisposableIterator.  Nothing in the existing JDK 
would be retrofitted with DisposableIterator.


Thanks... Sean

Neal Gafter wrote:
> On Tue, Sep 1, 2009 at 9:01 PM, Joshua Bloch <jjb at google.com 
> <mailto:jjb at google.com>> wrote:
> 
>     Many existing types will be retrofitted to extend Disposable.  If
>     such a type also implements Iterable, the semantics of a for-each
>     loop on an instance of the type would change, as I understand Sean's
>     suggestion.
> 
> 
> Josh-
> 
> In theory, yes.  However, I doubt you'll find a confluence of events 
> that would cause the change of behavior: (1) an existing implementation 
> of Iterable that make use of covariant returns to (2) return a type that 
> will be retrofitted with Disposable and is (3) used in a for-each loop 
> in some existing client code.  If you do find such a case, you've found 
> a resource leak in existing code, and its maintainers should be glad to 
> have the change in behavior.
> 
> -Neal