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

[Michael McMahon]

Hi Alex,

(and redirecting the thread to net-dev)

It looks like a straight forward solution and perhaps the compatibility test
could be challenged on the basis of reliance on implementation behavior 
rather than the spec.

But, more important I think is the behavior change of the fix itself and 
that will require
careful review which we can't commit to immediately. We will try and get 
back to you
about it in a week or so.

Thanks,

Michael.

On 14/03/2020 00:08, Alex Kashchenko wrote:
> Hi,
>
> Based on these maillist threads:
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html 
>
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html 
>
>
> I am looking for comments and suggestions, whether the following 
> change to JarURLConnection.getJarFile() behaviour may be acceptable:
>
> If, during connect() call, jarFile itself was created successfully, 
> but access to (non-existent) jarEntry failed - return this jarFile to 
> caller instead of throwing exception.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8132359
> webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
>
> This change also allows to fix JDK-8232854 with the minimal change to 
> URLClassPath (included with the patch).
>
> This change doesn't cause regression failures in java/net.
>
> This change causes one compatibility failure, when getManifest() 
> doesn't throw expected IOException when URL points to non-existent 
> class inside JAR.
>