Proposal: Automatic Resource Management (original) (raw)

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

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/thirdedition/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 duplicate();  } class A implements Duplicate, Duplicate {  public Integer duplicate() { return null;  }  }  and  interface Disposable {  public void dispose() throws E;  }  class Connection implements Disposable, Disposable {  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