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

[Johannes Kuhn]

Hi Joe,

thanks for all the info.
As I'm not yet familiar with the way how OpenJDK is developed, mind if I 
ask what steps would have to be taken to add Closeable to 
javax.naming.Context?
The first thing would be to create a patch, test it, run the tests.
Then the change has to be proposed, and reviewed. You can argue that 
this might waste the time of the reviewers with such a small patch.
Is there something else that would need to be done?

I have read http://openjdk.java.net/contribute/ and signed the OCA, but 
on the other hand, it's such a small change that most already know how 
the patch will look.
I am not even sure if my time would be spend wisely. The motivation 
would be to do it to learn how to contribute.

Anyway, thank you for your time and consideration. This just some stuff 
I found, then wrote some code, got some results and did not know what I 
can or should do with that.

Thanks,
Johannes

On 16-Apr-20 3:15, Joe Darcy wrote:
> 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
>>
>>