Automatic Resource Management, V.2

[Tom Ball]

My "vote" (I realize this isn't a democracy :-) is to avoid adding any new
rules, but instead keep it simple:  resources in source code go into all
tables like any other local variable currently does, while any
compiler-generated temporary variables get flagged as synthetic and are
included in any tables that include synthetic variables.  In other words, a
resource should be treated exactly like a local variable already is,
synthetic or not.  A resource is a local variable, after all, just one that
has some automatic cleanup as it leaves scope.

BTW, I like Bruce Chapman's suggestion that the type of a temporary variable
be AutoCloseable.  Since the only thing the compiler generated code will do
with that object is call its close() method, there's no advantage to it
having additional type information.

Tom

On Tue, Apr 21, 2009 at 9:48 AM, Neal Gafter <neal at gafter.com> wrote:

> On Tue, Apr 21, 2009 at 9:12 AM, Rémi Forax <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.
>
>