Automatic Resource Management, V.2

Reinier Zwitserloot reinier at
Mon Apr 20 03:47:17 PDT 2009

The usage of package 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 as well, so I doubt thats relevant.

A search through a lot of java libraries did not produce any (public  
API) results for 'AutoCloseable':

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/ 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!

On Apr 20, 2009, at 11:31, Stephen Colebourne wrote:

> 2009/4/20 Joshua Bloch <jjb at>:
>> * 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