Automatic Resource Management, V.2

Joshua Bloch jjb at google.com
Mon Apr 20 07:22:44 PDT 2009


Reinier,

These arguments are quite persuasive.  Let's see what (if anything) others
have to say, but I agree with you and Rémi at this point.

          Josh

On Mon, Apr 20, 2009 at 3:47 AM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> The usage of package java.lang.auto isn't neccessary; classes in your own
> package always take precedence over java.lang classes, and any import
> statement that clashes with a java.lang class takes precedence over
> java.lang.
>
> In other words, if there is an interface named 'jboss.AutoCloseable', then
> all classes in the jboss package will automatically use that AutoCloseable.
> Any code not in the jboss package that includes the statement "import
> jboss.AutoCloseable", will also use jboss's AutoCloseable. Client code (that
> is, code that USES trywith blocks) never needs to know about the name
> 'AutoCloseable' to use them. Any code that wants to be an ARM-style closable
> that is in jboss code will need be explicit:
>
> public class IAmClosable implements java.lang.AutoCloseable {
>     private AutoCloseable jbossAutoCloseable;
>     public void close() {}
> }
>
> but such code has to be explicit even if AutoCloseable was moved to
> java.lang.auto as well, so I doubt thats relevant.
>
> A search through a lot of java libraries did not produce any (public API)
> results for 'AutoCloseable':
>
> http://myjavadoc.net/search/search-java.php/AutoCloseable
>
>
> http://www.google.com/codesearch?hl=en&lr=&q=AutoCloseable+lang%3Ajava&sbtn=Search
>
> So it seems that org.jboss.remoting.spi.AutoCloseable is the only one.
>
> So, the only remaining issues are the following:
>
> A) Confusion for jboss and whatever other library(ies) are lurking out
> there with an AutoCloseable. Forgetting to import the
> 'right' AutoCloseable gets you the 'wrong' one. However, this confusion is
> pretty much unavoidable; just like when Iterable was added, seeing the words
> 'AutoCloseable' in a sourcefile will instinctivly make a java programmer
> think it must be java.lang.(auto.)AutoCloseable. There's a java puzzler
> dedicated to this principle, which creates a local version of String. In
> other words, putting AutoCloseable in another package doesn't help all that
> much. So, I say: not important enough; not enough applicable classes and the
> alternative doesn't clear up enough confusion.
>
> B) trying to import "jboss.*" will NOT take precedence over the implicit
> java.lang.* import; instead javac emits a compiler error:
>
> bar/Bar.java:7: reference to Integer is ambiguous, both class bla.Integer
> in bla and class java.lang.Integer in java.lang match
> Integer y = new Integer(12);
>
> So, its technically true there could be a migration compatibility issue,
> but I wouldn't be surprised if there isn't a single line of java code in
> existence that actually would run into this problem. I say: Not important
> enough; star imports are rarely used, there aren't many packages where this
> conflict can occur, java.lang.Iterable had the same problem and I've never
> seen a complaint there either, and a compiler error that hints at the
> problem (as above) is the next-best-thing to just working normally.
>
>
> If I weigh these issues against creating a new package in the java.lang
> space, as well as putting only 1 type inside it, as well as being
> inconsistent with how java.lang.Iterable was handled (which could easily
> have been put in java.util if this had been any concern back then) I think
> its clear that just putting AutoCloseable in java.lang is preferable.
>
>
>
>  --Reinier Zwitserloot
> Like it? Tip it!
> http://tipit.to
>
>
>
> On Apr 20, 2009, at 11:31, Stephen Colebourne wrote:
>
> 2009/4/20 Joshua Bloch <jjb at google.com>:
>
> * 3. Does the construct work properly with “decorated” resources?*
>
>    try (FileReader fr = new FileReader(path) {
>
>        try (BufferedReader br = new BufferedReader(fr) {
>
>            ... // Use buffered reader
>
>        }
>
>    }
>
>
> Would this section be better written:
>
>    try (FileReader fr = new FileReader(path); BufferedReader br = new
> BufferedReader(fr) {
>          ... // Use buffered reader
>    }
>
> ie. the second resource is derived from the first within one ARM block.
>
> (More generally, I think I'd prefer a single resource per ARM, as I
> think its a lot clearer overall and more consistent, but since you've
> allowed it in the proposal, I assume you'd want to keep to that
> style.)
>
> Stephen
>
>
>



More information about the coin-dev mailing list