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

[Mark Sheppard]

Hi Chris, 
sounds good .... thanks for the update 


regards 
Mark 



----- Original Message ----- 
From: chris.hegarty at oracle.com 
To: akashche at redhat.com, net-dev at openjdk.java.net, mark.sheppard at 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 < macanaoire at 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 < akashche at redhat.com > 
Sent: Monday 15 June 2020 10:35 
To: mark sheppard < macanaoire at hotmail.com >; OpenJDK Network Dev list < net-dev at openjdk.java.net > 
Cc: Mark Sheppard < mark.sheppard at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200615/ef833e5c/attachment.htm>