GlassFish build uses Maven (maven.apache.org) and like Ant the whole build happens in a single JVM. During build, we try to create, read, write many jar files. Randomly we see failures like "invalid block type" from the jar layer in JDK. It happens on all kinds of Unix platforms, can;t tell about Windows as I have not seen on Windows. It happens when we invoke maven (maven.apache.org) which is written in Java and is responsible for all the jar file processing. I am hoping that JDK team has sufficient serviceability tool to observe what's going on inside the process.

Here is how you can reproduce it:
1. svn co https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/javaee-api
Use your java.net id to login if need be.
2. cd javaee-api
3. JAVA_HOME=<Path to JDK 1.5> mvn install
Use mvn version 2.0.7.

Step #3 is where it all happens. First time, it will take a long time as maven has to download all the dependencies, but subsequent runs will be pretty fast. It bombs like this:

[INFO] [jar:jar]
[INFO] Building jar: /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.javaee/target/javax.javaee-10.0-SNAPSHOT.jar
[INFO] [bundle:bundle {execution: osgi-bundle}]
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] jzentry == 0,
jzfile = 137952112,
total = 8,
name = /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.transaction/target/javax.transaction-10.0-SNAPSHOT.jar,
i = 2,
message = invalid LOC header (bad signature)
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.InternalError: jzentry == 0,
jzfile = 137952112,
total = 8,
name = /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.transaction/target/javax.transaction-10.0-SNAPSHOT.jar,
i = 2,
message = invalid LOC header (bad signature)
       at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
       at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
       at aQute.lib.osgi.ZipResource.build(ZipResource.java:41)
       at aQute.lib.osgi.ZipResource.build(ZipResource.java:32)
       at aQute.lib.osgi.Jar.<init>(Jar.java:35)
       at org.apache.felix.bundleplugin.BundlePlugin.getClasspath(BundlePlugin.java:676)
       at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:227)
       at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:218)
       at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
       at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
       at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
       at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
       at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
       at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
       at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 7 seconds
[INFO] Finished at: Fri May 30 10:19:08 PDT 2008
[INFO] Final Memory: 20M/37M
[INFO] ---------------------------------------------------------------------
More information from submitter (sent to me via email):

It fails with several kinds of messages. The particular incidence reported in the bug report reports the message as : /invalid LOC header (bad signature)./ I have also seen messages like: /Embedded error: invalid distance code/, /invalid block type/, etc. If you follow the instructions to reproduce the bug, I am sure you can see all these messages when you run the command repeatedly. More over, on every occasion, it fails with different jar files. In every occasion, I have been able to open the offending jar file very successfully.