Hi Alex, I think there is some other work planned in this area, so it may be best to place this item on hold for a bit. There should be an update on this shortly.
regards Mark ________________________________ From: Alex Kashchenko <akash...@redhat.com> Sent: Monday 15 June 2020 10:35 To: mark sheppard <macanao...@hotmail.com>; OpenJDK Network Dev list <net-dev@openjdk.java.net> Cc: Mark Sheppard <mark.shepp...@oracle.com> Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found Hi, CSR: https://bugs.openjdk.java.net/browse/JDK-8244650 On 06/13/2020 10:49 PM, mark sheppard wrote: > 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. Thanks for your comments! Would it be appropriate to move the CSR to "Proposed" [1] at this point? > > [...] > [1] https://wiki.openjdk.java.net/display/csr/Main#Main-CSRWorkflows -- -Alex
