Automatic Resource Management, V.2

Joshua Bloch jjb at google.com
Mon Apr 20 14:07:55 PDT 2009


Neal,
On Mon, Apr 20, 2009 at 1:35 PM, Neal Gafter <neal at gafter.com> wrote:

> On Mon, Apr 20, 2009 at 1:26 PM, Joshua Bloch <jjb at google.com> wrote:
>
>> As for the "AutoCloseableItertor" stuff, I think it can wait for a
>> subsequent release. I see it as scope-creep that distracts from the
>> central
>> goals of the proposal and reduces the likelihood that it will be
>> successfully delivered into Java 7.
>
>
> If you don't design this now, you may well find it impossible to add later
> without introducing a breaking change.
>

That's always possible.  I'm not averse to thinking about it once the main
work is done.  I'd be especially interested in this functionality along with
some API changes to Scanner, which implements Iterator (not Iterable) and
has a close method but doesn't implement Closeable.  Right now, you can't
even use Scanner with a for-each loop, which is a shame.  If you could use
it (or some variant) with a for-each loop and the for-each loop
automatically closed the underlying character source, that would be nice; it
would eliminate a lot of boilerplate.

In C# (as you know) IEnumerator extends IDisposeable.  This is not an
unreasonable design if you're starting from a clean sheet.  We can't do
that, which means we'd need to add the notions of AutoCloseIterable, whose
iterator method returns an AutoCloseIterator, which extends both
AutoCloseable and Iterable.  The we'd have a for-each method whose behavior
differed depending on the static type of its iterable.  This is a bit scary,
in that it violates a fundamental API design guideline.  Is the result worth
this complexity?  Maybe.  I do like the idea of being able to say (roughly):

    for(String token : Scanner.fancyFactory(file)) {
       ... // Do something with the token
    }

Of course this would automatically close the underlying file, and there
would be different versions of the factory to read different types from the
file.  But we're a long way from that.

         Josh

            Josh



More information about the coin-dev mailing list