JDK-6387069 : java -jar z.jar fails when z.jar created using Info-zip
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-02-17
  • Updated: 2010-04-02
  • Resolved: 2006-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b79Fixed
Related Reports
Relates :  
JDK-6237956 - mustang b25 cannot extract data from zip files created by third-party zip implementations
Description
JDK 1.5.0 "java -jar ..." can no longer read some jar files created by
Info-Zip's zip command.

See self-explanatory shell transcript below:

 $ echo 'class Test {public static void main(String[] args) {}}' > Test.java && mkdir -p META-INF && (echo Manifest-Version: 1.0; echo Main-Class: Test) > META-INF/MANIFEST.MF && jver 1.4.2 javac Test.java && zip -q z.jar META-INF/MANIFEST.MF Test.class ; for v in 1.4.2 1.5.0 6.0; do echo $v; jver $v java -jar z.jar; done
1.4.2
1.5.0
Invalid or corrupt jarfile z.jar
6.0
Invalid or corrupt jarfile z.jar
Comments
SUGGESTED FIX Read the local header from the jar file to get the length of the extra field to allow the actual location of the manifest file data to be located.
20-03-2006
EVALUATION It should also be noted that the jar file created using Info-ZIP still isn't quite a jar file. Jar files are tagged with "0xcafe" in the extra field of the first local header. Note that this is not within the suggested usage of this field as it doesn't start with "registered header ID" followed by "length of header", but it is history (sigh). Currently, this additional tagging of jar files is only used in the system identification of "executable jar files" on UNIX (Solaris and Linux). jar files contructed using anything other than the jar utility can't be directly executable.
20-03-2006
EVALUATION I'm very sorry I failed to connect the dots and suggest the source of failure discovered by the other evaluator, since I fixed 6237956: mustang b25 cannot extract data from zip files created by third-party zip implementations which had the same root cause and similar symptoms. /* The Zip file spec explicitly allows the LOC extra data size to * be different from the CEN extra data size, although the JDK * never creates such zip files. Since we cannot trust the CEN * extra data size, we need to read the LOC to determine the entry * data offset. We do this lazily to avoid touching the virtual * memory page containing the LOC when initializing jzentry * objects. (This speeds up javac by a factor of 10 when the JDK * is installed on a very slow filesystem.) */
20-03-2006
EVALUATION The issue is that the java launcher (parse_manifest.c) contains the assumption that the extra field length in the central directory will be equal to the extra field length in the local directory. Info zip defies this assumption. The length of this field is used in locating the start of the actual file data. Its interesting to speculate what Info-Zip is doing. In this case, the local extended entry contains a 9-byte "extended timestamp" entry followed by a 4-byte "Info-ZIP UNIX (new)" entry for a total (including headers) of 21 bytes. The central extended entry contains a 5-byte "extended timestamp" entry followed by an empty (zero-byte) "Info-ZIP (new)" entry. I can't even venture a guess as to what they hope to accomplish by this, but it doesn't matter, the spec doesn't prohibit these from being different, so the implementation (ours) should get the length of the extra field length from the local header rather than from the central header.
19-03-2006
EVALUATION What's the difference between the jar files created by jar and zip? Not STORED vs. DEFLATED; we tried that. jar adds "Created-By"; that doesn't seem to be it either. jar changes LF to CR LF. That is currently the most likely suspect. We should examine parse_nv_pair some more.
17-02-2006