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-boun...@openjdk.java.net> on behalf of Alex Kashchenko <akash...@redhat.com> Sent: Wednesday 10 June 2020 14:52 To: OpenJDK Network Dev list <net-dev@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
