-
Bug
-
Resolution: Fixed
-
P4
-
1.2.0, 1.3.0, 1.4.2_04, 6
-
b48
-
generic, x86
-
generic, windows_xp
-
Verified
Name: boT120536 Date: 05/20/2001
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)
When JarURLConnections to entries inside a JarFile are opened, the jarfile is
cached, even when caching is explicitly turned off.
Under Win32 systems, this has the side-effect that the file can no longer be
modified (e.g. deleted). Under Linux this only results in filedescriptors being
kept open as can be seen with 'lsof'.
The source below reproduces this problem, assuming that there is a jarfile
called 'localfile.jar'.
--- BEGIN SOURCE ---import java.io.File;
import java.io.InputStream;
import java.net.URL;
import java.net.URLConnection;
/**
* This class shows the caching bug in JarURLConnection
*
* @author ###@###.###
*/
public class JarURLConnectionTestCase
{
/**
* This method opens a local file, opens a non-caching
* URLConnection, opens a Stream on that connection, closes the
* stream and tries to delete the file.
*
* On Win32 systems, this will cause an exception because the file
* is still referenced by the URLConnection-cache
*/
public static void main(String[] args)
throws Exception
{
URL entryURL
= new URL("jar:file:localfile.jar!/META-INF/MANIFEST.MF");
URLConnection connection = entryURL.openConnection();
// BUG: turn off caching; this does NOT work
connection.setUseCaches(false);
// open and close a stream
InputStream stream = connection.getInputStream();// causes the caching
stream.close();
// now delete the file. This fails, because the connection
// keeps a cache-reference
File file = new File("localfile.jar");
System.err.println("Attempting to delete localfile.jar");
if (!file.delete()) {
System.err.println("Deletion failed, bug exists!");
}
}
}
--- END SOURCE ---
According to our profiler, the caching happens in
sun.net.www.protocol.jar.JarFileFactory:80
(Review ID: 124469)
======================================================================
- duplicates
-
JDK-4991099 Applications need a way to close jar files opened by java.net.URLClassLoader and
- Closed
-
JDK-6630027 URLClassLoader should have an explicit disposal mechanism
- Closed
-
JDK-4175918 URLConnection should define disconnect() method
- Closed
- relates to
-
JDK-4166799 URL-downloaded jar files (jar_cache files) never get deleted
- Resolved
-
JDK-6349735 Internal API for closing jar files belonging to URLClassLoader instances
- Resolved
-
JDK-6501408 URLClassLoader loads resources from incorrect / out-of-date jar and suspected corruption/sigsegv
- Closed
-
JDK-8013099 (sl) ServiceLoader interferes with URLClassLoader.close()
- Closed