JDK-7177701 : error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic,x86
  • Submitted: 2012-06-17
  • Updated: 2012-07-11
  • Resolved: 2012-07-11
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.
7u6Fixed 8 b45Fixed
Random build failure seen in recent jdk 8 & 7u6 builds.
error: Filling jar:file:/tmp/jprt/P1/213916.scoffey/s/build/solaris-sparc/tmp/rt-orig.jar!/java/lang/Comparable.class during ZipFileIndexFileObject[/tmp/jprt/P1/213916.scoffey/s/build/solaris-sparc/tmp/rt-orig.jar(javax/imageio/metadata/IIOMetadataFormatImpl.class)]
1 error
1 warning
make[2]: *** [initial-image-jdk] Error 1

SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7

EVALUATION I created a script that invokes the CreateSymbols annotation processor 100 times and report any failures during execution. I found out that, out of 100 runs, there were around 10 failures (the exact number of failures varies with time). If the script was modified so that the new hash changes were disabled (by setting the system property Djdk.map.althashing.threshold=-1) the failures disappeared. This means the failure must be related to the hash changes. I then looked closer at the code in CreateSymbols.java, and found that the call to JavaFileManager.list() was not indexing all files in the input archives in a consistent order - more specifically, the order was changing each time CreateSymbols was executed (which is a very typical side-effects of the new hash changes). If JavaFileManager.list() is modified so that it returns files listed in a consistent, non-random order - the issue goes away (i.e. no failures out of 100 runs). Of course this is only a temporary workaround that will buy us some time in order to figure out what the underlying issue exactly is - but at least it should be enough to get rid of the random build failures that have been seen recently.