Feedback and comments on ARM proposal

[Joshua Bloch]

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<X extends Exception>
> 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.

<snip>


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