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
