Proposal: Automatic Resource Management

[Rémi Forax]

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