Automatic Resource Management, V.2

[brucechapman at paradise.net.nz]

Quoting Tom Ball <tball at google.com>:

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

And I think (despite Josh's explanation for why the source code desugaring can't
be AutoClosable) that the fact that AutoClosable.close() throws Exception
instead of something specific (or nothing), doesn't matter in the class file
format because the compiler will have already dealt with the specific (if any)
possible exceptions on the actual (possible intersection or recursive) type of
the resource expression by either ensuring that they are caught, or declared
thrown in the enclosing method. The only nit here would be if the verifier did
Exception checking and complained that Exception was not caught, but I don't
think that is the case (from a quick browse of the verifier spec, tho I am in NO
WAY AT ALL knowledgable about such things). 

-anyone know for sure??

Bruce

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