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-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.
