Hi Chris, sounds good .... thanks for the update
regards Mark ----- Original Message ----- From: chris.hega...@oracle.com To: akash...@redhat.com, net-dev@openjdk.java.net, mark.shepp...@oracle.com Sent: Monday, 15 June, 2020 1:46:06 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found Hi Alex, Mark, While I think that change for this issue is good, I would like to request that we please put it on hold temporarily. I will experiment with possible solutions for 8246714 - the URLClassLoader issue. It may result in no overlap with this issue, 8132359, but it seems prudent to allow that experimentation to happen first. Sorry to be asking that this issue wait, I don’t do this lightly or often, but it seems like the right thing to do. -Chris. On 15 Jun 2020, at 13:05, mark sheppard < macanao...@hotmail.com > wrote: 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
