Automatic Resource Management, V.2

Rémi Forax forax at
Tue Apr 21 10:30:38 PDT 2009

Neal Gafter a écrit :
> On Tue, Apr 21, 2009 at 9:12 AM, Rémi Forax <forax at 
> <mailto: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.
If the type is not AutoCloseable, the compile emit a checkcast before 
calling close(),
so it will work even if i agree that this checkcast can be avoided.


More information about the coin-dev mailing list