Automatic Resource Management, V.2

Neal Gafter neal at
Tue Apr 21 09:48:06 PDT 2009

On Tue, Apr 21, 2009 at 9:12 AM, Rémi Forax <forax at> wrote:

>> You can probably avoid this mess by being explicit about the specification
>> rather than attempting the "as-if" rewriting.  If a construct like this is
>> to be integrated into the JLS that would probably be required anyway, and
>> a
>> new set of issues is likely to be exposed by the attempt.  It would be
>> better to get the specification wrung out earlier rather than later (I
>> don't
>> think Alex will be eager to do it himself).
> Why the local var need to be visible in these tables ?
> The compiler already introduced new local var , by example, in case of
> ++/-- and
> compound assignments on boxed type (using the hidden instruction LetExpr).
> In that case the local var is flagged SYNTHETIC and doesn't appear in local
> vars tables.

Right: if the specification is spelled out, one can decide on a case-by-case
basis how to handle the mapping to the class file. However, you can't avoid
these variables appearing in the verifier tables at the very least.  In that
case the natural type based on the current spec is its erasure, which is not
necessarily AutoCloseable.

More information about the coin-dev mailing list