Automatic Resource Management, V.2

Stephen Colebourne scolebourne at
Mon Apr 20 10:24:11 PDT 2009

2009/4/20 Joshua Bloch <jjb at>:
>> Why not return a List<Throwable> instead of an array (since
>> Collections are generally nicer to use)?
> I did think about this, but I opted to stick with the pattern in enum types'
> values() method.  That decision was made for performance. Arguably the
> performance issues are less important here, and the winds of change have
> blown further away from arrays since then, so I'm definitely open to
> switching this to a List if others think it's the right thing to do.

Definitely List. Arrays should be considered a deprecated type in all
JDK arrays at this point IMO. We need to move beyond thinking about
raw performance as a reason.

For example, I would have much preferred Enums to have had a Map of
name to enum as a generated method. I currently have to have a code
generator create this for every enum I write.

>> > The printStackTrace method should be modified to append the stack traces
>> for any suppressed exceptions.
>> This might be difficult, particularly where there are a number of
>> "cause" and "suppressed" exceptions (each of which might have their
>> own) - it might be hard to associate each exception with its parent in
>> the output (whereas currently "cause" has only one immediate parent
>> and so it is easy to follow such a stack trace).
> I did think about this, and came to the conclusion that it wasn't so bad.
>  The main problem is the "intermingling" of causes and suppressed
> exceptions.  I will come up with a format and put an example in the spec.

The proposal should strive to include enhanced stack traces.

> >    (More generally, I think I'd prefer a single resource per ARM, as I
> >    think its a lot clearer overall and more consistent, but since you've
> >    allowed it in the proposal, I assume you'd want to keep to that
> >    style.)
> Yes.  May people really care about keeping the nesting depth low, and
> the ability to combine resources in a single ARM statement does that for them.

In my own work, I would probably choose to go with a code convention
requiring each ARM block to only have a single declaring variable.


More information about the coin-dev mailing list