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 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 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 true.
In this latter case, if opening the entry throws an exception,
it can't close the jar file because the file might have come from
the cache and it might still be used by someone else.
But because getJarFile() calls connect() then there's no way
to retrieve the jar file through that (failed) connection.
I agree that fixing the issue in URLClassPath is probably the
less risky.
I see that your test caters for all possible setting of uses cache
and combination of success/failure when opening the jar entry,
so this give me confidence that the fix is working as intended.
best regards,
-- daniel
On 24/11/2019 15:33, Rob McKenna wrote:
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 will fail as the JarFile is still in use (i.e. open)
despite the fact that the loader has been closed.
Note: the behaviour depends on the URLConnections useCaches setting so
the test cycles through the combinations. (this helpfully found a problem
with an earlier fix attempt)
bug: https://bugs.openjdk.java.net/browse/JDK-8132359
webrev: http://cr.openjdk.java.net/~robm/8132359/webrev.01/
Thanks,
-Rob
