Automatic Resource Management, V.2

[Tom Ball]

Things language and compiler-related are only ever obvious in hindsight. :-)

On Tue, Apr 21, 2009 at 11:17 AM, Joshua Bloch <jjb at google.com> wrote:

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