Proposal: Automatic Resource Management

[Joshua Bloch]

Neal,

On Sat, Feb 28, 2009 at 7:41 AM, Neal Gafter <neal at gafter.com> wrote:

> Josh-
>
> The compatibility section must document incompatibilities, whether or
> not you judge them likely to cause problems in practice.


Good point.  I will add this one.  And I am still interested in whether
anyone can find some code in an existing codebase that tickles this.

>
>
> To be complete at a level suitable for project coin, you should
> provide a specification of all of the semantics.  For example, there
> is nothing comparable to JLS section 11.2.2, exception analysis, which
> for this construct is much more complex than the existing statements
> and therefore must be spelled out.


I have done so in the  "Semantics and Compilation" section: it's implicit in
the desugaring. The project lead (Joe Darcy) said this in a personal
communication: "I suppose the desugarings should cover issues related to
flow analysis with the new statement form." Of course we can translate the
desugaring into JLS-ready prose when the time comes, but I don't think it
would aid in understanding the proposal.

 Particularly concerning to me is
> the fact that this translation would sometimes silently swallow
> exceptions indicating serious program failures


Unless I am missing something, the construct only "silently swallows"
exceptions when they are intentionally suppressed in favor of prior
exceptions, which typically indicate more serious problems.  I did describe,
in the "Additional Features" section, a facility whereby suppressed
exceptions are associated with the exception for which they were suppressed:

Here are several features that might be added to the construct if the expert
group deemed it advisable:

Retaining suppressed exceptions - As described above, the construct simply
discards exceptions
that are suppressed. It would probably be better to attach them to the
exception in whose favor they
are being suppressed. This would entail adding two new methods to Throwable,
void
addSuppressedException(Throwable) and Throwable[] getSuppressedExceptions().


I do think this is worth doing, and I will "promote it" to the body of the
proposal if that is the consensus.

  If the variable becomes null before the
> finally block, is NullPointerException thrown?


As per the desugaring, the resource variable is implicitly final.  In any
practical use, you'll get an NPE in the explicit block, but yes, if you
construct an artificial example where the resource is not actually used,
you'll get a NullPointerException in the (implicit) close, again as per the
desugaring.


>  What if the variable
> is assigned to some other value?


It won't compile, as the variable is implicitly final.  My guess is that you
had a hard time reading the desugaring due to the lack of formatting.  I'll
send you the pdf:)


>  Does this construct then close some
> other resource than the one opened?


Sorry, but I don't understand this question.  Again, I suspect the
desugaring will make this clear.


>  These questions should be clear
> from the spec, and for these questions the answer is either unclear or
> quite unlikely to be what you intend.


I don't think this is true.  In each case you've mentioned, the behavior was
intentional and is clearly specified by the desugaring.  I believe that it
would be straightforward to translate the desugaring into JLS-style prose,
but I don't think it would improve the proposal.  As the proposal says, my
intent was to "emphasizes brevity and clarity."



>  The fact that you proposed two
> possible but semantically distinct translations suggests that not all
> is settled.


Sorry for the confusion.  I did this for pedagogical reasons.  The first
translation was meant to quickly explain the construct. The second was meant
to add a desirable feature, and should be regarded as correct.  I could
remove the first one from the proposal and go straight to the second, but
I'm afraid the resulting proposal would be harder to understand.  I will add
prose to clarify that the second desugaring supersedes the first.


>
>
> In the C# world, the using statement has the "shoehorning" issue that
> I described.  I can tell you from experience that it does encourage
> clients to implement the IDisposable interface, and a method named
> Dispose, to use the pattern, even though that may be very unnatural to
> the API.  It is a flaw in the language that we're aware of and working
> to repair.


I have little experience with C# so I'll have to defer to you on issues
concerning this language.  But in Python, I am led to understand that the
with statement is very well liked.  The same goes for the the RAII pattern
in C++.  The need for automatic resource management in Java is made
abundantly clear by the fact that 2/3 of the uses of the close method in the
JDK are wrong.  I myself got it wrong (twice) in java.util.prefs. And our
solution on page 88 of Java Puzzlers is also wrong: it silently swallows the
exception when closing a file that was open for write.

           Josh