Automatic Resource Management, V.2
Reinier Zwitserloot
reinier at zwitserloot.com
Mon Apr 20 03:47:17 PDT 2009
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