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
c: Mark Sheppard
> Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
> file is not found
>
> Hi,
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
> <https://bugs.openjdk.java.net/browse/JDK-8244650>
>
> On 06/13/2020 10:49 PM, mark sheppard wro
Network Dev list
Cc: Mark Sheppard
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
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
appear that
there is merit in this fix.
regards
Mark
From: net-dev on behalf of Alex Kashchenko
Sent: Wednesday 10 June 2020 14:52
To: OpenJDK Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
file is not found
Hi
On 06/10/2020 03:52 PM, Alex Kashchenko wrote:
Hi,
On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
A question about this CSR: after this new issue was found in the same area:
JDK-8246714: URLClassLoader/JAR protocol handler poisons the glo
Hi,
On 05/12/2020 12:20 AM, Alex Kashchenko wrote:
CSR: https://bugs.openjdk.java.net/browse/JDK-8244650
A question about this CSR: after this new issue was found in the same area:
JDK-8246714: URLClassLoader/JAR protocol handler poisons the global
JarFile cache under concurrent load
would
On 10/05/2020 21:51, Alex Kashchenko wrote:
Thanks for your comments!
On 05/08/2020 06:38 PM, Michael McMahon wrote:
[...]
https://bugs.openjdk.java.net/browse/JDK-8244650
I believe some sort of spec change will be needed, if only to justify
challenging the JCK. Currently, the proposed c
Thanks for your comments!
On 05/08/2020 06:38 PM, Michael McMahon wrote:
[...]
https://bugs.openjdk.java.net/browse/JDK-8244650
I believe some sort of spec change will be needed, if only to justify
challenging the JCK. Currently, the proposed change trips the following
test:
TestCase: [Jar
On 08/05/2020 17:34, Daniel Fuchs wrote:
Hi Alex,
On 08/05/2020 15:35, Alex Kashchenko wrote:
On 05/06/2020 01:11 PM, Michael McMahon wrote:
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
Hi Alex,
On 08/05/2020 15:35, Alex Kashchenko wrote:
On 05/06/2020 01:11 PM, Michael McMahon wrote:
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.
I'
On 05/06/2020 01:11 PM, Michael McMahon wrote:
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()
om: net-dev on behalf of mark
sheppard
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon ; Alex Kashchenko
Cc: Mark Sheppard ;
net-dev@openjdk.java.net >> OpenJDK Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource
leak when file is not found
Hi
Sent: Wednesday 1 April 2020 16:03
To: Michael McMahon ; Alex Kashchenko
Cc: Mark Sheppard ; net-dev@openjdk.java.net >> OpenJDK
Network Dev list
Subject: Re: RFC: 8132359: JarURLConnection.getJarFile() resource leak when
file is not found
Hi Michael et al.,
just looking
; net-dev@openjdk.java.net >>
OpenJDK Network Dev list
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 implic
2:39
To: Alex Kashchenko
Cc: net-dev@openjdk.java.net >> OpenJDK Network Dev list
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 compatibili
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
I'm afraid so.
The option of changing the the JarURLConnection spec to indicate what
could happen when the class file is missing was discussed but that will
require some further thought. (and it may not necessarily result in a fix
for this problem, the assumption being that behaviour changes in th
Daniel's summary is useful but changing URLClassPath doesn't feel right.
Are you in a hurry to find a solution to this? Just asking as I think
I'd prefer to see other options explored that fixed it in the protocol
handler instead.
-Alan
On 25/11/2019 13:31, Rob McKenna wrote:
Thanks Danie
Thanks Daniel,
cc'ing core-libs-dev in case there are any objections.
-Rob
On 25/11/19 10:47, Daniel Fuchs wrote:
> Hi Rob,
>
> That looks good to me. I wonder if that should go to corelibs for
> review as well.
>
> The underlying issue here is that JarURLConnection open both its
> jar fil
Hi Rob,
That looks good to me. I wonder if that should go to corelibs for
review as well.
The underlying issue here is that JarURLConnection open both its
jar file and its jar file entry in its connect() method.
However, it delegates the opening of the jar file to the cache,
when uses cache is t
Hi folks,
If a FileNotFoundException is thrown when attempting to load a class
from a jar file, a reference to the open JarFile remains even after the
loader is closed. The test in the webrev demonstrates the problem by
attempting to delete the JarFile after attempting a class load.
The deletion
Peter,
I just tried disabling caching via call to
urlConnection.setUseCaches(false) prior to my call to getJarFile() in my
test code and that does prevent the resource leak in test scenario. So that
is one possible workaround when I am anticipating that the file will not
exist in the jar file.
Al
You're right, Neon!
I thought I saw close() somewhere in JarURLConnection, but it seems I
saw it somewhere else.
Peeking at code, I think it would help if you did:
jarUrlConnection.setUseCaches(false);
before invoking:
jarUrlConnection.getJarFile()/getJarEntry()/connect();
In case caches
There are no close(), disconnect(), or similar method on
java.net.JarURLConnection nor it's super class (java.net.URLConnection).
My sample test program will close the resource when searching for an
"existing" file inside the jar file.
It only has resource leak (open file descriptor) when searchin
On 08/17/2015 04:02 PM, Neon Ngo wrote:
The test program below shows a resource leak in java.net.JarURLConnection's
getJarFile() when given an non-existent file to lookup in the jar file.
Under Windows, the last printout shows that it is not able to remove the test
input jar file.
Any input
The test program below shows a resource leak in
java.net.JarURLConnection's getJarFile() when given an non-existent
file to lookup in the jar file.
Under Windows, the last printout shows that it is not able to remove
the test input jar file.
Any input jar file can be used to test this as long as i
27 matches
Mail list logo
