Proposal: Automatic Resource Management

[Neal Gafter]

Remi-

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

-Neal

On Wed, Mar 4, 2009 at 4:58 AM, Rémi Forax <forax at univ-mlv.fr> 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)
> <http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#78598>,
> 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
>
>
>
>
>