Proposal: Automatic Resource Management

[Xavi Miró]

I see this iterator autoclean construction very powerful but as a 
potential user of it I would prefer a slightly different syntax. The 
current proposal would change the semantics of existing programs, as 
Josh has pointed, and although it is likely that it wouldn't break 
existing programs, I think a different syntax would make clearer for a 
programmer to see it would do something more than the current foreach 
construction. I mean I would prefer something like:

(1)

try for (final Row row: table) {
    ...
}

or

(2)

for (final Row row: table) try {
    ...
}

instead of

(3)

for (final Row row: table) {
    ...
}

For me it's easier to understand with (1) or (2) that it's going to 
_try_ to do something _for_ each of those elements; it will iterate and 
for each element it will autoclean. With (3) I can see the same 
construction we use today, "for each element do this" and depending on 
the version of Java it will only iterate or it will iterate and 
autoclean. I know that only with elements that implement a Disposable 
interface it would autoclean, but in order to actually know it I must 
check the interfaces (which can be in another source code file); with a 
different syntax I could know it instantly.

In addition, if we use a different syntax the compiler can complain if 
the elements don't implement Disposable, so if the programmer forgets to 
make them implement it he or she can notice it. If the syntax is the 
same, forgetting to implement the interface would be silently ignored 
and the programmer would think the elements would be cleaned up and they 
would not.

The (1) and (2) syntax are only two possibilities, maybe we can find a 
better one, but in my humble opinion it would be best to differentiate 
the different semantics with different syntaxes.

Regards,

    Xavi

Sean R. Drucker escribió:
> 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
>>     
>
>
>