Feedback and comments on ARM proposal (original) (raw)

Joshua Bloch jjb at google.com
Fri Mar 13 11:05:48 PDT 2009

Hi Mark,

On Fri, Mar 13, 2009 at 7:25 AM, Mark Mahieu <markmahieu at googlemail.com>wrote:

It may be worth persevering with the Adapter interface for a little longer though, as it is something we can parameterize with the exception type. If it's going to be returned by an adapter method rather than implemented directly by the resources, perhaps the Adapter interface should extend AutoCloseable itself: interface AutoCloseableAdapter extends AutoCloseable { void close() throws X; } A problem with this is that parameterizing the exception type thrown by a method doesn't work very well (as I'm sure you're aware). Methods can be declared to throw multiple exceptions, but Java doesn't provide any way of expressing this disjunction of types. Therefore, users of an interface prameterized in the exception thrown by a method have to make do with the "least common ancestor" of all the unchecked exceptions thrown by the method. Usually this is java.lang.Exception, which is unacceptable.

The main concern I have about this approach in general is that the variable declaration might be a little too 'magical' : you appear to start out with a resource (a Path, to continue previous themes), call a method to turn it into something completely different, then assign that to a variable of the type you started out with. Possibly a bit confusing, given a syntax that uses the assignment operator anyway.

I would tend to agree with you on this.

Bob Lee conjectures that we simply don't need adapters: that AutoCloseablesolves a sufficiently large fraction of the cases of interest that it's all we need. He has investigated many of the cases that aren't addressed by this interface, and finds them uncompelling. But neither Bob nor I are GUI programmers by trade. Bob suggested that I put together a freely writable Google doc that would allow all of us to collaborate on compiling a list of types for which this automatic resource management might be of interest. This document could help us assess and refine the proposal. The criteria for deciding whether a type is appropriate for automatic resource management are simple: (1) Typical use of the type must require "lexically scoped resource management." In other words, best practice dictates that the resource be disposed of in the same scope that it was created. This is true for some but not all types with close/dispose methods. (2) The type must be in very common use; if a type is rarely used, it barely matter whether the construct handles it. I have created a document for this purpose ( http://docs.google.com/Doc?id=ddv8ts74_1d7tz65fd), and anyone who wants can add to it. Please participate (constructively)!

     Thanks,

     Josh

More information about the coin-dev mailing list