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

[mark sheppard]

Hi,
   For JDK-8132359 it now addresses the issue:

Amend JarURLConnection::getJarFile() to return JarFile object reference for nonexistent JAR file entry URL

The scenario addressed is that a JarURLConnection is constructed encapsulating a reference to an non existent entry in an extant JarFile, then the  getJarFile  is reasonably expected to return a reference to the associated JarFile, rather than propagating the IOException thrown by the implicit JarURLConnection::connect invocation  in getJarFile.

The original test case demonstrates other cross platform issues in this context. But by returning the JarFile reference, ( rather than propagating the exception,)  it is then possible to invoke close on the JarFile, and allow the explicit delete of the JarFile. Thus, mitigating a perceived problem on Windows.

As such, this is an issue in its own right, and as such it would appear that there is merit in this fix.

regards
Mark



________________________________
From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Alex Kashchenko <akashche at redhat.com>
Sent: Wednesday 10 June 2020 14:52
To: OpenJDK Network Dev list <net-dev at openjdk.java.net>
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found

Hi,

On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650

A question about this CSR: after this new issue was found in the same area:

JDK-8246714: URLClassLoader/JAR protocol handler poisons the global
JarFile cache under concurrent load

would it be appropriate to postpone the activity on the CSR (and
possibly eventually cancel it)?

It looks like both possible solutions to 8244650:

  - short term: disable caching for JAR protocol

  - long term: rework JAR protocol handler

make this CSR redundant.

I am happy to work on some minor bugfixes in this area if necessary.

>
> [...]
>
--
-Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200613/762a5588/attachment.htm>