Community
Participate
Working Groups
We have a product in which we redistribute the headless parts of the jdt. This product is using pack200 internally for all features and bundles. At present, we cannot build the product unless we exclude these two fragments from the pack phase: org.eclipse.jdt.compiler.apt_1.0.100.v20080414-2145.jar org.eclipse.jdt.compiler.tool_1.0.100.v_858.jar Stacktraces printed by the eclipse.jarProcessor ant-task during the pack phase: Exception in thread "Main Thread" java.lang.SecurityException: SHA1 digest error for org/eclipse/jdt/internal/compiler/apt/dispatch/AnnotationDiscoveryVisitor.class at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:194) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:411) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) at java.io.FilterInputStream.read(FilterInputStream.java:66) at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:43) at java.io.DataInputStream.readInt(DataInputStream.java:370) at com.sun.java.util.jar.pack.ClassReader.readMagicNumbers(ClassReader.java:139) at com.sun.java.util.jar.pack.ClassReader.read(ClassReader.java:122) at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:490) at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:464) at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73) at com.sun.java.util.jar.pack.Driver.main(Driver.java:261) Exception in thread "Main Thread" java.lang.SecurityException: SHA1 digest error for org/eclipse/jdt/internal/compiler/tool/Archive.class at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:194) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:201) at java.util.jar.JarVerifier.update(JarVerifier.java:188) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:411) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) at java.io.FilterInputStream.read(FilterInputStream.java:66) at com.sun.java.util.jar.pack.ClassReader$1.read(ClassReader.java:43) at java.io.DataInputStream.readInt(DataInputStream.java:370) at com.sun.java.util.jar.pack.ClassReader.readMagicNumbers(ClassReader.java:139) at com.sun.java.util.jar.pack.ClassReader.read(ClassReader.java:122) at com.sun.java.util.jar.pack.PackerImpl$DoPack.readClass(PackerImpl.java:490) at com.sun.java.util.jar.pack.PackerImpl$DoPack.run(PackerImpl.java:464) at com.sun.java.util.jar.pack.PackerImpl.pack(PackerImpl.java:73) at com.sun.java.util.jar.pack.Driver.main(Driver.java:261)
Would you have more information on the reason why pack200 flags these .class files as having a problem? I.e. why is pack200 throwing this SecurityException?
(In reply to comment #1) > Would you have more information on the reason why pack200 flags these .class > files as having a problem? I.e. why is pack200 throwing this SecurityException? > No, not much. I get the error when I include them in a zip and pass that zip to the eclipse.jarProcessor ant task with the pack="true" jar="<the zip>". No other options are given. The zip contains a lot of other jars, both from the platform and from our application. None of them pose any problems. Just these two. The zip passes through a 'normalize' without erros prior to the pack attempt but during that phase I guess nothing should happen to these fragments since their eclipse.inf marks them as processed already.
Olivier, does this ring any bell?
These two jars are the only ones compiled using a compliance 1.6. So maybe this is a bug in pack200 that cannot handle stack map attributes.
> The zip passes through a 'normalize' without erros prior to the pack attempt > but during that phase I guess nothing should happen to these fragments since > their eclipse.inf marks them as processed already. I think the jar may be getting re-normalized. Normally this should not be an issue. See however bug 226850, fixed in M7. The SDK conditions/packs all of its jars using effort level 4 because we have seen some .class file corruption in the past using the default level 5. This bug 226850 could potentially cause the jars to be reconditioned using a different effort level, which may cause problems. Try updating the org.eclipse.update.core bundle in your builder to get the fix. As well, you could try lowering the effort level to 4 for all your bundles. Do this by placing a pack.properties file in the root of the zip with a property "pack200.default.args=-E4"
Thomas, Did Andrew hint fix your issue ?
No, lowering the effort didn't help so we removed the pack of those jars. I suspect that it might be related to another issue with Pack200 not working correctly with J9 version 6. See bug 279596.
There is nothing we can do from our side. Closing as NOT_ECLIPSE ?
Closing as NOT_ECLIPSE.
Verified for 3.6M1
