JDK 1.4.1, Windows 2000.

When JarURLConnection uses setUseCaches(true) - which is the default - and the jar file it reads changes underneath, then JarURLConnection will get confused and is unable to read the zip file.

See also http://www.netbeans.org/issues/show_bug.cgi?id=31573 for more information.

To reproduce:
1. Create JarURLConnection that caches the jar/zip file
2. Read all entries of the jar/zip file in a loop
3. Programatically replace the jar/zip file by another one (from the same VM)
4. Read all entries again

The following exception will be thrown:
java.lang.InternalError: jzentry == 0,
 jzfile = 258096688,
 total = 8,
 name = c:\jdkbug\test.zip,
 i = 2,
 message = invalid LOC header (bad signature)
        at java.util.zip.ZipFile$2.nextElement(ZipFile.java:309)
        at java.util.jar.JarFile$1.nextElement(JarFile.java:201)
        at JarURLConnectionBug.readJar(JarURLConnectionBug.java:51)
        at JarURLConnectionBug.main(JarURLConnectionBug.java:32)

I am attaching a zip file containing the following:
- a small test which reproduces the problem
- zip archives as test data
- output of the test which shows the exception


Note: I just checked on JDK 1.4.2 beta and the bug still occurs, although with a different message:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x77FCA200
Function=RtlDestroyHeap+0x311
Library=C:\WINNT\System32\ntdll.dll

Current Java thread:
        at java.util.zip.ZipFile.getNextEntry(Native Method)
        at java.util.zip.ZipFile.access$400(ZipFile.java:26)
        at java.util.zip.ZipFile$2.nextElement(ZipFile.java:313)
        - locked <0x10032118> (a sun.net.www.protocol.jar.URLJarFile)
        at java.util.jar.JarFile$1.nextElement(JarFile.java:211)
        at JarURLConnectionBug.readJar(JarURLConnectionBug.java:51)
        at JarURLConnectionBug.main(JarURLConnectionBug.java:32)

Dynamic libraries:
0x00400000 - 0x00406000 c:\j2sdk1.4.2\bin\java.exe
0x77F80000 - 0x77FF9000 C:\WINNT\System32\ntdll.dll
0x77DB0000 - 0x77E0A000 C:\WINNT\system32\ADVAPI32.dll
0x77E80000 - 0x77F36000 C:\WINNT\system32\KERNEL32.DLL
0x77D40000 - 0x77DAF000 C:\WINNT\system32\RPCRT4.DLL
0x78000000 - 0x78046000 C:\WINNT\system32\MSVCRT.dll
0x08000000 - 0x08136000 c:\j2sdk1.4.2\jre\bin\client\jvm.dll
0x77E10000 - 0x77E75000 C:\WINNT\system32\USER32.dll
0x77F40000 - 0x77F7C000 C:\WINNT\system32\GDI32.DLL
0x77570000 - 0x775A0000 C:\WINNT\System32\WINMM.dll
0x10000000 - 0x10007000 c:\j2sdk1.4.2\jre\bin\hpi.dll
0x007C0000 - 0x007CE000 c:\j2sdk1.4.2\jre\bin\verify.dll
0x007D0000 - 0x007E8000 c:\j2sdk1.4.2\jre\bin\java.dll
0x007F0000 - 0x007FD000 c:\j2sdk1.4.2\jre\bin\zip.dll
0x77920000 - 0x77942000 C:\WINNT\system32\imagehlp.dll
0x72A00000 - 0x72A2D000 C:\WINNT\system32\DBGHELP.dll
0x690A0000 - 0x690AB000 C:\WINNT\System32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation total 576K, used 153K [0x10010000, 0x100b0000, 0x104f0000)
  eden space 512K, 29% used [0x10010000, 0x10036638, 0x10090000)
  from space 64K, 0% used [0x10090000, 0x10090000, 0x100a0000)
  to space 64K, 0% used [0x100a0000, 0x100a0000, 0x100b0000)
 tenured generation total 1408K, used 0K [0x104f0000, 0x10650000, 0x14010000)
   the space 1408K, 0% used [0x104f0000, 0x104f0000, 0x104f0200, 0x10650000)
 compacting perm gen total 4096K, used 1030K [0x14010000, 0x14410000, 0x18010000)
   the space 4096K, 25% used [0x14010000, 0x14111930, 0x14111a00, 0x14410000)

Local Time = Mon Apr 07 20:13:23 2003
Elapsed Time = 1
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-beta-b19 mixed mode)
#
# An error report file has been saved as hs_err_pid4628.log.
# Please refer to the file for further information.
#
 

There is one more thing I forgot: to use the attached test case, you need to modify the path to the jar file on lines 25-28.

Also, there is another strange thing about JarURLConnection: When you get the JarFile from the connection, and then close() it, and then obtain the JarURLConnection again, there does not seem to be a way to read from the jar again, as it complains that it is closed. This is when you use the caching mode.

###@###.### 2003-04-07