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

[Johannes Kuhn]

updated the code, similar output. Disregard org/w3c/dom/html/HTMLDocument
https://gist.github.com/DasBrain/df25a69acf564dcb5f2241cc065be2ed

About java.xml.stream: A XMLStreamReader is for example constructed with:

     BufferedReader br = ...;
     XMLStreamReader xsr = 
XMLInputFactory.newDefaultFactory().createXMLEventReader(br);

For my IDE this would look like XMLStreamReader wraps the 
BufferedReader, so it won't issue a warning if I don't close br.
But the Javadoc for XMLStreamReader.close() states:

 > Frees any resources associated with this Reader. This method does not 
close the underlying input source.

If those classes would implement AutoCloseable, people and IDEs might 
wrongly assume that it would close the BufferedReader.
Which would result in code like this:

     try (var xsr = 
XMLInputFactory.newDefaultFactory().createXMLEventReader(Files.newBufferedReader(path, 
StandardCharsets.UTF_8))) {  ... }

And have a resource leak. Incidentally, that is the similar to the code 
I tried to write when I saw that XMLStreamReader has a public void 
close() method.
So in my opinion, to let XMLStreamReader implement AutoCloseable, the 
specification of the close() method should be changed.

The same applies for the other XML Stream/Event Reader/Writer.

Thanks,
Johannes

On 16-Apr-20 9:28, Alan Bateman wrote:
> On 16/04/2020 01:28, Johannes Kuhn wrote:
>> :
>>
>> I did not restrict my enumeration to public and exported types - it 
>> was easier not to do that and I'm lazy.
> Most of the candidates that you've identified are JDK internal classes 
> and there are several non-public classes in exported packages. There 
> are also a few cases where the sub-classes of the likely candidate are 
> showing up too (e.g. all the public sub-classes of 
> java.util.logging.Handler). I skimmed through your list and filtered 
> it down to the public classes in exported packages to following:
>
> com/sun/jdi/connect/spi/Connection
> java/awt/SplashScreen
> java/util/logging/Handler
> javax/naming/Context
> javax/naming/NamingEnumeration
> javax/naming/ldap/StartTlsResponse
> javax/smartcardio/CardChannel
> javax/sql/PooledConnection
> javax/swing/ProgressMonitor
> javax/xml/stream/XMLEventReader
> javax/xml/stream/XMLEventWriter
> javax/xml/stream/XMLStreamReader
> javax/xml/stream/XMLStreamWriter
>
> As Joe points out, some of these may have been looked at already. I 
> was surprised to see the java.xml.stream reader/writers so it might be 
> worth digging into those to see why they were not retrofitted.
>
> -Alan.
>
>
>