RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

[Alex Kashchenko]

Hi,

CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

On 05/11/2020 02:28 PM, Michael McMahon wrote:
 >
 > [...]
 >
 > I think for the avoidance of doubt we should make the same change to the
 > getManifest() @Throws spec also,
 > to cover the above. There is another method getMainAttributes() whose
 > behavior will also change,
 > but I think its existing spec covers it, since it depends on 
getManifest()

I've added the change to getManifest() @return instead using the same 
wording as in getJarFile(), because it clarifies the case when exception 
is not thrown, and it was a bit misleading having it in @throws.


On 05/11/2020 10:17 PM, mark sheppard wrote:
> Hi Michael et al.,
>      wrt the actually bug itself and its title should it be changed to something more appropriately
> aligned with the fix?
> something like
> Amend JarURLConnection::getJarFile() to return JarFile object reference for non existent jar file entry URL.

Changed the title of the CSR and of the original issue.


> 
> [...]
> 
> So looking at the API docs
> 
> the getJarEntry method references getJarFile, - @see #getJarFile (and itself getJarEntry - the @see #getJarEntry should probably be removed),
> indicating some dependency association with getJarFile method. However, as it is overridden in the implementation subclass, any anticipated getJarFile().getJarEntry(entryName) is never invoked.
> 
> However,  the @throws says the following:
> IOException if getting the Jar file for this connection causes an IOException to be thrown
> 
> and as "getting the Jar file" doesn't cause an IOException, this should probably be amended to
> 
> IOException if getting the Jar file for this connection causes an IOException to be thrown,
> or the referenced entry does not exist in the containing Jar file.

Added this change to getJarEntry() @throws, rephrasing it slightly to 
match getJarFile() wording, and clarifying that with the changed 
behaviour its existing @throws spec is no longer correct.


> should the overridden methods in sun.net.www.protocol.jar.JarURLConnection be qualified with the
> @Override annotation ?

I haven't included this change, please let me know if it is necessary to 
include it.


> 
> [...]
>

-- 
-Alex