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

Fri May 1 09:32:37 UTC 2020

Hi,

Pinging politely about this issue.

I wonder whether it would be appropriate to file a CSR about 
getJarFile() behaviour change at this point?

Concise description of the change is:

"So should the getJarFile return be a reference to JarFile for an URL 
specifying an non existent entry  i.e. the resource doesn't exist?"

On 04/02/2020 12:14 AM, mark sheppard wrote:
>   p.s.
> 
> I had also meant to say in the response below, that the proposed getJaFile solution is
> perfectly reasonable and would allow a recoverable strategy in an related
> scenario where a URLConnection:: connect,  for the same type of entry URL,
> throws a FNFException resulting in the same type of "resource leak".
> But, in this case, with the proposed change the JarFile can be retrieved and closed.
> 
> regards
> Mark
> 
> 
> 
> ________________________________
> From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of mark sheppard <macanaoire at hotmail.com>
> Sent: Wednesday 1 April 2020 16:03
> To: Michael McMahon <michael.x.mcmahon at oracle.com>; Alex Kashchenko <akashche at redhat.com>
> Cc: Mark Sheppard <mark.sheppard at oracle.com>; net-dev at openjdk.java.net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
> Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
> 
> Hi Michael et al.,
>      just looking at the webrev ... the change in URLClassPath seems reasonable.
> The change in JarURLConnection  has implications and would change the semantics of
> the getJarFile method.
> 
> using the example accompanying this JBS item to demonstrate an issue caused by the caching mechanism
> within the URLConnection framework, it should be noted that the jar URL is referencing
> an non existent entry in the jar file entry. Thus some form of exception would be anticipated in this scenario.
> 
> With the proposed change, this will return a JarFile regardless of whether a referenced resource (URL) exists or not.
> 
> Examining  the call flows it can be observed that
> the getJarFile invokes connect. This will retrieve a jar file via JarFileFactory
>   and then, because the URL references an entry in the jar file, attempts
>   to access the entry resulting in a  null return,  which generates a FNF exception to be thrown.
> 
> Also note that an explicit invocation of connect on the JarURLConnection instance will result in the FNFException.
> 
> the change in the JarURLConnection will return a jar file in this test scenario and not the FNF exception. Based on the methods
> spec is that acceptable behaviour change?
> 
> 
> public abstract JarFile getJarFile throws IOException
> 
> Return the JAR file for this connection.
> 
> Returns:
> the JAR file for this connection. If the connection is a connection to an entry of a JAR file, the JAR file object is returned
> Throws:
> IOException<https://docs.oracle.com/javase/7/docs/api/java/io/IOException.html> - if an IOException occurs while trying to connect to the JAR file for this connection.
> See Also:
> URLConnection.connect()<https://docs.oracle.com/javase/7/docs/api/java/net/URLConnection.html#connect()>
> and connect says
> "Opens a communications link to the resource referenced by this URL, if such a connection has not already been established."
> 
> So should the getJarFile return be a reference to JarFile for an URL specifying an non existent entry  i.e. the resource doesn't exist?
> Is the resource associated with a JarURLConnection the encapsulated JarFile? Or the target in the specified  in the URL ?
> 
> There are a series of similar behaviour anomalies in this area URL/URLConnection/JarURLConnection (on Windows) and in general they
> can be attributed to the internal caching  mechanism, which is enabled OOTB, and its impact on the closing of file resource in Exception conditions scenarios.
> 
> Disabling caching for jar protocol , which will allow consistent and correct behaviour is one possibility.
> 
> As such an alternative or workaround  is to disable caching for the jar protocol
> via the URLConnection::setDefaultUseCaches() on Windows where an application
> may want to delete a jar file resource, for example:
> 
> URLConnection.setDefaultUseCaches("jar", false);
> 
> best regards
> Mark
> 
> ________________________________
> From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Michael McMahon <michael.x.mcmahon at oracle.com>
> Sent: Monday 16 March 2020 12:39
> To: Alex Kashchenko <akashche at redhat.com>
> Cc: net-dev at openjdk.java.net >> OpenJDK Network Dev list <net-dev at openjdk.java.net>
> Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when file is not found
> 
> Hi Alex,
> 
> (and redirecting the thread to net-dev)
> 
> It looks like a straight forward solution and perhaps the compatibility test
> could be challenged on the basis of reliance on implementation behavior
> rather than the spec.
> 
> But, more important I think is the behavior change of the fix itself and
> that will require
> careful review which we can't commit to immediately. We will try and get
> back to you
> about it in a week or so.
> 
> Thanks,
> 
> Michael.
> 
> On 14/03/2020 00:08, Alex Kashchenko wrote:
>> Hi,
>>
>> Based on these maillist threads:
>>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065076.html
>>
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063643.html
>>
>>
>> I am looking for comments and suggestions, whether the following
>> change to JarURLConnection.getJarFile() behaviour may be acceptable:
>>
>> If, during connect() call, jarFile itself was created successfully,
>> but access to (non-existent) jarEntry failed - return this jarFile to
>> caller instead of throwing exception.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8132359
>> webrev: http://cr.openjdk.java.net/~akasko/jdk/8132359/webrev.00/
>>
>> This change also allows to fix JDK-8232854 with the minimal change to
>> URLClassPath (included with the patch).
>>
>> This change doesn't cause regression failures in java/net.
>>
>> This change causes one compatibility failure, when getManifest()
>> doesn't throw expected IOException when URL points to non-existent
>> class inside JAR.
>>
> 

-- 
-Alex