Proposal: Automatic Resource Management

[Neal Gafter]

Josh-

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

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.  Particularly concerning to me is
the fact that this translation would sometimes silently swallow
exceptions indicating serious program failures (this too should be
listed among the disadvantages); completing the exception analysis
specification would make that problem more obvious.  What are the
completion analysis rules?  If the variable becomes null before the
finally block, is NullPointerException thrown?  What if the variable
is assigned to some other value?  Does this construct then close some
other resource than the one opened?  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.  The fact that you proposed two
possible but semantically distinct translations suggests that not all
is settled.

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.