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
