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

Wed May 6 12:11:54 UTC 2020

Hi,

Yes, we've had some discussion about it internally, and while others may
yet have an opinion, I think this approach is a reasonable one, with a 
spec change
that captures the behavior.

The main thing we need to capture is that while connect() to a non 
existing resource
may fail, getJarFile() can still return a reference to the containing 
JAR file if that is accessible.

There could be other subtleties like what happens if the JAR file is not 
accessible,
is null a reasonable return value in that case? I think that could 
happen and might
need to be specified.

Michael.

On 01/05/2020 10:32, Alex Kashchenko wrote:
> 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.
>>>
>>
>
>