Automatic Resource Management, V.2

[Joshua Bloch]

Tom,

Thanks!  This seems like the obvious correct solution.  I feel like a fool
for not having done it that way in the first place.

           Josh

On Tue, Apr 21, 2009 at 10:24 AM, Tom Ball <tball at google.com> wrote:

> 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.
> >
> >
>
>