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-boun...@openjdk.java.net> on behalf of mark sheppard
<macanao...@hotmail.com>
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon <michael.x.mcma...@oracle.com>; Alex Kashchenko
<akash...@redhat.com>
Cc: Mark Sheppard <mark.shepp...@oracle.com>; net-dev@openjdk.java.net >>
OpenJDK Network Dev list <net-dev@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-boun...@openjdk.java.net> on behalf of Michael McMahon
<michael.x.mcma...@oracle.com>
Sent: Monday 16 March 2020 12:39
To: Alex Kashchenko <akash...@redhat.com>
Cc: net-dev@openjdk.java.net >> OpenJDK Network Dev list
<net-dev@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.
>
