Automatic Resource Management

Joshua Bloch jjb at google.com
Mon Apr 13 09:38:30 PDT 2009


Allen,
Hi.  Thanks for taking the time to read the proposal.

On Mon, Apr 13, 2009 at 9:26 AM, Allen, Chris
<Chris.Allen at nationalcity.com>wrote:

> I've looked at Automatic Resource Management proposal, and written this
> email and then sat on it for several days, and it seems that the current
> proposal, adding a Disposable interface, is arbitrarily restrictive and
> that by using an attribute combined with a signature matching we could
> get better bang for our buck.


We discussed this extensively (you can find it in the archive) and Sun made
it clear that this violates the "prime directive" concerning the use of
annotations: they are not permitted to change program semantics.

I floated a related proposal involving the use of "finally" as a modifier
(again, you can find it in the archive), but it necessarily involved changes
to the class file format, the tool chain, etc.  The consensus was that this
was too big a change for Coin, and probably to big a change for the added
benefit.  Moreover, the added flexibility came with added potential for
trouble (how do you ensure that there is a unique disposal method on a given
type, or deal with the situation where there's more than one?).


>
>
> As an aside, one of the ideas that needs to be promoted in any of these
> proposals, is the idea that the exception thrown during the main life of
> the resource receives priority over any exception thrown by the dispose
> method(s).  This is a fantastic idea, but sounds fishy at first glance.
> By responsibly closing your resource even during some catastrophic event
> you can actually erase what the catastrophic event was and waste many
> hours of debugging.  This idea needs to be made clear: the proposal
> doesn't not hide the dispose exception, just doesn't favor it when
> competing with the primary exception.


  I'm hard at work on a revision, and hope to have it out later today.  I
will  make sure to make this clear.


>
>
> We already have a lot of JDK code out there and a good portion of it
> does not use close() as it's dispose method.


That's true, and this facility won't cover everything right away.  But it
will cover enough types to pay for itself and it will cover more over time.
 And in the worst case, you can cover arbitrary types by writing adapters.

           Regards,

           Josh



More information about the coin-dev mailing list