Proposal: Automatic Resource Management

Neal Gafter neal at
Wed Mar 4 06:47:51 PST 2009


Do you have any evidence that this is a sound extension of the type system?


On Wed, Mar 4, 2009 at 4:58 AM, Rémi Forax <forax at> wrote:
> Joshua Bloch a écrit :
>> Mark,
>> Sorry for the delay, and thanks so much for the report!  This is an
>> interesting case.  It seems unfortunate that DataCacheManagerImpl extends
>> Closeable, given that its close method doesn't throw any checked exceptions.
>>  But it got me thinking, and I came to the conclusion that there's no reason
>> for the Disposable interface to be parameterized!  Its close method should
>> just throw Exception.  Then Closeable and DataCacheManager can both extend
>> Disposable. The Disposable interface won't be terribly useful as a parameter
>> type, but who cares? Its raison d'etre is the  automatic resource management
>> statement.  In this context, the close method is invoked on a resource using
>> its declared type.  That means that it throws whatever exceptions it's
>> declared to throw (as per the desugaring in my proposal).  I will modify the
>> proposal accordingly and repost it.  I think this is a real improvement!
>>  It's both simpler and more broadly applicable.
>>        Thanks so much,
>>        Josh
> There is another way, change the JLS :)
> In my opinion, the last sentence of  section 8.1.5 of the JLS is too
> restrictive:
> "A class may not at the same time be a subtype of two interface types which
> are different invocations of the same generic interface (§9.1.2)
> <>,
> or an invocation
> of a generic interface and a raw type naming that same generic interface."
> This sentence is weird because the last part of section 8.1.5 explain
> how to detect clash between methods from different interfaces
> by taking a look to their return types.
> So in case of different interfaces, the compiler have to do a calculation
> involving the member methods but if interfaces are generics
> it doesn't do any calculation on member methods.
> That is not consistent.
> Note than the detection algorithm is not exactly the same because
> one can have a clash between bridge methods.
> I'm proposing to remove the last sentence of section 8.1.5
> and replace it by a one saying that if there is of two or more
> generics super-interfaces, member methods of their raw types
> should not have the same signature.
> With theis new rule, the following examples will now compile:
> interface Duplicate<X> {
>       X duplicate();
>    }
> class A implements Duplicate<Integer>, Duplicate<Number> {
>    public Integer duplicate() {
>       return null;
>    }
>  }
>    and
>    interface Disposable<E> {
>      public void dispose() throws E;
>    }
>    class Connection implements Disposable<IOException>,
> Disposable<Exception> {
>      public void dispose() throws IOEXception {
>      }
>    }
> There is another reason why I don't like the last sentence of section 8.1.5,
> this sentence is not compatible with section 13.4.4 on binary compatibility:
> "Changing the direct superclass or the set of direct superinterfaces of
> a class type will not break compatibility
> with pre-existing binaries, provided that the total set of superclasses
> or superinterfaces,
> respectively, of the class type loses no members."
> cheers,
> Rémi

More information about the coin-dev mailing list