Automatic Resource Management, V.2
Rémi Forax
forax at univ-mlv.fr
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 univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> 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.
Rémi
More information about the coin-dev
mailing list