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
