Some Classes with a public void close() don't implement AutoCloseable

[Joe Darcy]

Hi Johannes,

FYI, back during Project Coin during JDK 7, there were various 
systematic efforts to review types with a "close" method in the JDK and 
retrofit AutoCloseable where appropriate:

     JDK-6911261: Project Coin: Retrofit Automatic Resource Management 
(ARM) support onto platform APIs
     https://bugs.openjdk.java.net/browse/JDK-6911261

     JDK-6963723: Project Coin: Retrofit more JDK classes for ARM
     https://bugs.openjdk.java.net/browse/JDK-6963723

If you'll excuse the bad import into another blogging system, the 
process of finding the candidate types with an annotation processor and 
doing the retrofitting was discussed in a blog entry from that time:

https://blogs.oracle.com/darcy/project-coin:-bringing-it-to-a-closeable


More recently fixed in JDK 14,

     JDK-8203036: com.sun.net.httpserver.HttpExchange should implement 
AutoCloseable
     https://bugs.openjdk.java.net/browse/JDK-8203036

and as of August 2019, closed as will not fix given lack of interest:

     JDK-7057061: Support autocloseable for javax.naming.Context
     https://bugs.openjdk.java.net/browse/JDK-7057061

Thanks,

-Joe

On 4/15/2020 5:28 PM, Johannes Kuhn wrote:
> After failing to wrap a XMLStreamReader in a try-with-resources after 
> discovering it's close() method,
> I thought about checking what other classes have a public void close() 
> method in the JDK but don't implement AutoCloseable.
>
> So I wrote a small program that enumerates all classes present in in 
> the jrt image with a public void close() method that does not
> directly or indirectly implement AutoCloseable:
> https://gist.github.com/DasBrain/8d50e02e35654870e2c2c00bf3f79954 
> (Output & Code, Code requires JDK 14 with preview features and ASM)
>
> As I am not an expert in any of those areas where classes showed up, 
> and I don't know if it was an oversight, or if there is a good reason 
> for not implementing AutoCloseable.
> Implementing AutoCloseable is a double edged sword, a few IDEs warn 
> about resource leaks based on that interface.
> And treat an AutoCloseable passed to methods who return an 
> AutoCloseable as the return value wraping the parameter.
>
> I did look at a few classes:
> * javax.xml.stream.XMLStreamReader:Javadoc: "Frees any resources 
> associated with this Reader. This method does not close the underlying 
> input source." Better not implement it?
> * javax.naming.Context: Javadoc: "This method releases this context's 
> resources immediately, instead of waiting for them to be released 
> automatically by the garbage collector." Implement AutoCloseable?
> * java.util.logging.Handler: Lifecycle seems to be managed by a 
> LogManager. Better not implement AutoCloseable?
> * jdk.internal.jrtfs.ExplodedImage: class is package private, 
> overrides close() from SystemImage while increasing visibility to public.
>
> I did not restrict my enumeration to public and exported types - it 
> was easier not to do that and I'm lazy.
>
> This touches many unrelated areas, but David Holmes suggested that I 
> take it to core-libs-dev.
> I know, I just did some static code analysis, but it seems that there 
> might be some low hanging fruits.
> And for public classes I wish to have at least some rationale why a 
> class with a public void close() method doesn't implement AutoCloseable.
>
> Thanks,
> Johannes
>
>