Community
Participate
Working Groups
Build ID: M20080221-1800 Steps To Reproduce: 1. Install Eclipse 3.3.2 for linux ppc gtk on a ppc linux machine 2. Put IBM Java 6.0 (J9VM - 20080415_0187623_bHdSMr) on the machines 3. Start up Eclipse 4. Use Help->Software Updates->Find and Install.. to install any feature (e.g. the CDT) The features will appear to download correctly, but after you click the "Install all" button, you will get an error dialog pop up, with the text: 'Unable to complete action for feature "..." due to errors.' Under that, there are a number of files in the /tmp directory that it says are not valid jar files. More information: Note that this problem does not occur with IBM Java 5.0, and does not happen with Eclipse 3.4. Here's a stack dump from the .metadata/.log file: !SESSION 2008-08-19 10:49:22.995 ----------------------------------------------- eclipse.buildId=M20080221-1800 java.fullversion=J2RE 1.6.0 IBM J9 2.4 Linux ppc-32 jvmxp3260-20080415_18762 (JIT enabled, AOT enabled) J9VM - 20080415_018762_bHdSMr JIT - r9_20080415_1520 GC - 20080415_AA BootLoader constants: OS=linux, ARCH=ppc, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch ppc -clean !ENTRY org.eclipse.update.core 4 0 2008-08-19 10:59:36.102 !MESSAGE Unable to complete action for feature "Eclipse Communication Framework Core API (Required)" due to errors. !STACK 1 org.eclipse.core.runtime.CoreException: The File "/tmp/1292856569/eclipse/.update/1219161302308/1219161302310/eclipse10830.tmp" is not a valid JAR file. [error in opening zip file] at org.eclipse.update.core.Utilities.newCoreException(Utilities.java:223) at org.eclipse.update.core.Utilities.newCoreException(Utilities.java:254) at org.eclipse.update.internal.verifier.CertVerifier.init(CertVerifier.java:86) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:129) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:373) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:370) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:483) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) org.eclipse.core.runtime.CoreException[0]: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:146) at java.util.jar.JarFile.<init>(JarFile.java:110) at org.eclipse.update.internal.verifier.CertVerifier.init(CertVerifier.java:77) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:129) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:373) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:370) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:483) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 1 org.eclipse.update.core 4 0 2008-08-19 10:59:36.110 !MESSAGE The File "/tmp/1292856569/eclipse/.update/1219161302308/1219161302310/eclipse10830.tmp" is not a valid JAR file. [error in opening zip file] !STACK 0 java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:146) at java.util.jar.JarFile.<init>(JarFile.java:110) at org.eclipse.update.internal.verifier.CertVerifier.init(CertVerifier.java:77) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:129) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:373) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:370) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:483) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 1 org.eclipse.update.core 4 0 2008-08-19 10:59:36.111 !MESSAGE The File "/tmp/1292856569/eclipse/.update/1219161302308/1219161302310/eclipse10830.tmp" is not a valid JAR file. [error in opening zip file] !STACK 0 java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:146) at java.util.jar.JarFile.<init>(JarFile.java:110) at org.eclipse.update.internal.verifier.CertVerifier.init(CertVerifier.java:77) at org.eclipse.update.internal.verifier.CertVerifier.verify(CertVerifier.java:129) at org.eclipse.update.core.Feature.verifyReferences(Feature.java:967) at org.eclipse.update.core.Feature.install(Feature.java:377) at org.eclipse.update.internal.core.SiteFile.install(SiteFile.java:96) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:155) at org.eclipse.update.internal.core.ConfiguredSite.install(ConfiguredSite.java:119) at org.eclipse.update.internal.operations.InstallOperation.execute(InstallOperation.java:92) at org.eclipse.update.internal.operations.BatchInstallOperation.execute(BatchInstallOperation.java:84) at org.eclipse.update.internal.ui.wizards.InstallWizard2.install(InstallWizard2.java:373) at org.eclipse.update.internal.ui.wizards.InstallWizard2.access$1(InstallWizard2.java:370) at org.eclipse.update.internal.ui.wizards.InstallWizard2$1.run(InstallWizard2.java:483) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
One additional thing to note is that this problem does not occur on x86 linux gtk (I tried just now, using the latest IBM Java 6.0). So this is ppc-specific, which implies to me that there is a problem with the JRE 6.0.
I need to retract one thing said in this bugzilla. Eclipse 3.4 has problems with IBM Java 6.0 also. The features install without errors, but when you go to restart Eclipse, it cannot read the jar files from the feature that was added. The jar files are shorter than they should be, and are unreadable with "unzip -l ...". Running "file" on the jar files just says "data".
I filed a bug report against IBM Java 6.0 GA and SR1 and got back an email saying to try the latest overnight build. That build, which is on its way to becoming IBM Java 6.0 (SR2), no longer exhibits the problem described in this bugzilla. I will leave this bug open until the official SR2 comes out and I've had a chance to test it.
IBM Java 6.0 SR2 is out now, and does *partially* fix the problem. Under Eclipse 3.4, new features now download, install, and work properly. However, under Eclipse 3.3.2, the problem remains. After the dialog pops up that asks if I want to "Install" or "Install All", and I click Install All, an error dialog pops up saying the the tmp files it has downloaded are not recognized as jar files. Just to reiterate, Eclipse 3.3.2 works fine with IBM Java 5.0 under the identical scenario.
Could you please give a try to a 3.5 build?
The 3.5M* builds work fine.
Can I suggest another experiment/work-around? This is an off-the-wall wild guess, but just in case ... Where you see the error, do you have JAVA_HOME set? I ask because I've seen a similar issue (bug 269778) and I have NOT systematically investigated, but seems it works in some builds, but not others, and in the case I saw the error, JAVA_HOME is not set. Again ... total guess. Different context. Could be a dozen other explanations. But, the "locate pack200" routine does in some cases fall back on JAVA_HOME so there might be some error with finding the "correct" pack200 and having JAVA_HOME set explicitly might help it find the right executable to unzip jar.pack.gz files. Just a guess.
Thank you for the suggestion, David. I didn't explicitly set JAVA_HOME, but when I logged in, I was surprised to find it set to /usr/lib/jvm/java. I tried unsetting JAVA_HOME then tried the install experiment again... same problem. So then I pointed JAVA_HOME at the install location of the IBM JAVA (/opt/ibm/java-ppc-60) and then repeated the experiment again. Still fails. If I look in the configuration details while eclipse is running, I see: java.home=/opt/ibm/java-ppc-60/jre As a final experiment, I tried setting JAVA_HOME to /opt/ibm/java-ppc-60/jre and then ran eclipse, but the problem persists.
I should add that I'm fairly certain that this is not a problem with the unpacking routines, but something to do with downloading. When I look in the /tmp directory where the downloaded files are when the error comes up, there are a bunch of .tmp files in there, and only one is registering as a zip/jar file. This tells me something got corrupted during the download. I'm a bit puzzled by the fact that there are both the *.tmp.pack.gz files in there as well as the .tmp files. What is the .pack suffix? If I gunzip the .tmp.pack.gz file, the perform some operation on the .tmp.pack file, will I get the .tmp file? Googling around a little, I found that someone else had the same exact problem with the Eclipse 3.3 / IBM Java 1.6.0 combination. You can see the thread here and it appears they never found a solution: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14058071
(In reply to comment #9) > I should add that I'm fairly certain that this is not a problem with the > unpacking routines, but something to do with downloading. > > When I look in the /tmp directory where the downloaded files are when the error > comes up, there are a bunch of .tmp files in there, and only one is registering > as a zip/jar file. This tells me something got corrupted during the download. > I'm a bit puzzled by the fact that there are both the *.tmp.pack.gz files in > there as well as the .tmp files. What is the .pack suffix? If I gunzip the > .tmp.pack.gz file, the perform some operation on the .tmp.pack file, will I get > the .tmp file? > No. Probably not. The "pack" signifies "pack200" was used to compress the file. See http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html the "tmp" there signifies some stage of download or unpacking, but not sure what. You might try setting the org.eclipse.update.jarprocessor.pack200 system property as described in http://wiki.eclipse.org/Pack200#Pack200_Executable_location Perhaps even setting to "@none"! Just to test.
I also meant to say, the java.home=/opt/ibm/java-ppc-60/jre looks correct. At least on my install, there does exist, from there, /bin/pack200 and / bin/unpack200. But ... maybe some interaction with that old version causes some wrong version to be found/used. Or ... perhaps those "old" jars were packed with less modern methods than we use today :)
Interesting. So I tried the obvious thing: invoke unpack200 on the .pack file and I get this: IBM Java 5.0 % /opt/ibm/java2-ppc-50/jre/bin/unpack200 eclipse519934380569013193.tmp.pack y.jar % file y.jar y.jar: Zip archive data, at least v1.0 to extract IBM Java 6.0 % /opt/ibm/java-ppc-60/jre/bin/unpack200 eclipse519934380569013193.tmp.pack y.jar elm3b18:corey-213% file y.jar y.jar: data You put your finger on the bug! I wonder if this is an IBM Java bug or something else. I filed an IBM Java bug report on this Eclipse problem many months ago, but didn't have much to go on. This is *very* concrete now. Any additional thoughts before I send this off to the IBM Java support team?
(In reply to comment #12) > > Any additional thoughts before I send this off to the IBM Java support team? > It might be best to give them (and for you to test) the original pack.gz file, instead of what was downloaded since technically, there could be some special problem with (only) the downloaded file). Do you have the exact name? I'd assume you would have unpacking with Java 5. If you give me the jar's name, I can get and attach the pack.gz version here. And, of course, usually helps to verify with another vendor's VM to see if same incorrect behavior or not.
Created attachment 131472 [details] Example of pack file which is incorrectly unpacked by IBM Java 6 for ppc This .pack.gz file unpacks differently (and incorrectly) on Linux PowerPC IBM Java 6. The file does correctly unpack on the following platforms: Linux PowerPC: IBM Java 5.0 Linux x86: IBM Java 6.0 Linux x86: IBM Java 5.0 Windows x86: Sun Java 6.0 I haven't tried other combinations. However, I think I successfully narrowed the problem down to the unpack stage rather than the gunzip stage, because I manually ran gunzip on the file, then used unpack200 on the resulting .pack file and the result was the same: doesn't work on Linux PowerPC IBM Java 6.0, but works on the others above.
> It might be best to give them (and for you to test) the original pack.gz file, > instead of what was downloaded since technically, there could be some special > problem with (only) the downloaded file). Do you have the exact name? I don't know how to determine the exact (original) name of the file. All I have are the temp names that come out in the "Problem Occurred" dialog as follows: Unable to complete action for feature "Eclipse C/C++ Development Tools" due to errors. The File "/tmp/1292856569/eclipse/.update/1239300898064/1239300898066/eclipse519934380569013193.tmp" is not a valid JAR file. [error in opening zip file] error in opening zip file The File "/tmp/1292856569/eclipse/.update/1239300898064/1239300898066/eclipse519934380569013193.tmp" is not a valid JAR file. [error in opening zip file] error in opening zip file > I'd > assume you would have unpacking with Java 5. If you give me the jar's name, I > can get and attach the pack.gz version here. I've attached it, but I don't have the original name. Not that most of the downloaded files have the same problem, and it doesn't really matter which one I pick. > > And, of course, usually helps to verify with another vendor's VM to see if same > incorrect behavior or not. > See previous attachment comment. Verified on Windows x86 Sun Java... pretty far removed, I think. Also linux 86 IBM Java works fine too... there's something peculiar with the PowerPC variant, it appears.
Typo in the last comment: It typed, "Not that most of the downloaded files have the same problem ...", I meant, "Note that most of the ..."
Sounds like you have what you need to report the bug. Remember, to work around the issue from an Eclipse install point of view, you should be able to specify -Dorg.eclipse.update.jarprocessor.pack200="@none" to avoid any issue with pack.gz files.
Hold on, before you report a bug ... you might want to be sure you have/get the latest service version. I think there might even be an SR3 now? Mine install is java version "1.6.0" Java(TM) SE Runtime Environment (build pxp3260sr2-20080818_01(SR2)) IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux ppc-32 jvmxp3260-20080816_22093 (JIT enabled, AOT enabled) J9VM - 20080816_022093_bHdSMr JIT - r9_20080721_1330ifx2 GC - 20080724_AA) JCL - 20080808_02 And I just tried all the pack.gz files directly from downloads machine, ~/downloads/eclipse/updates/3.2/plugins/*.pack.gz and they all seemed to unpack ok.
Thanks. I am actually running the latest release - SR4. I filed Eureka PMR 56301,001,866
I just confirmed that adding the -Dorg.eclipse.update.jarprocessor.pack200="@none" switch to the command line which starting Eclipse does work around this problem. Thank you very much, David. Nice to get this (more or less) off my plate!
(In reply to comment #20) > I just confirmed that adding the > -Dorg.eclipse.update.jarprocessor.pack200="@none" > switch to the command line XwhichX starting Eclipse does work around this when > problem.
See bug 279596 for similar case. Also, just for cross-reference, please note, that due to decision in bug 273540 that with Galileo discovery site, the option to use -Dorg.eclipse.update.jarprocessor.pack200="@none" will not help (since jar files are not stored on server, if there is a pack.gz version). In those cases, a Java 5 VM 'pack/unpack' will need to be used, such as -Dorg.eclipse.update.jarprocessor.pack200=${JAVA_5_HOME}/jre/bin
(In reply to comment #22) > See bug 279596 for similar case. > > Also, just for cross-reference, please note, that due to decision in bug 273540 > that with Galileo discovery site, the option to use > -Dorg.eclipse.update.jarprocessor.pack200="@none" > will not help (since jar files are not stored on server, if there is a pack.gz > version). > In those cases, a Java 5 VM 'pack/unpack' will need to be used, such as > -Dorg.eclipse.update.jarprocessor.pack200=${JAVA_5_HOME}/jre/bin > Yikes! It's a very important issue, then. It may take users quite awhile to figure out why installation of new features is not working. This IBM Java 6 bug is supposed to be fixed in SR5, but I don't know when SR5 will be out. I think they release SR's about every 6 months. SR4 came out on Feb 19, so if it's 6 months, SR5 should be due on ~July 20th.
I just looked through the SR's that have been released for IBM Java 6: GA: 2007/11/23 SR1: 2008/04/16 SR2: 2008/08/18 SR3: 2008/11/06 SR4: 2009/02/19 So that's roughly 5 months, 4 months, 3 months, 4 months. So it's not a rigid schedule. And by the way, I miscalculated.. if it is 6 months, we won't be due until August 19, but looking at the above, we should see a new SR between now and the end of July.
IBM Java 6.0 SR5 came out this last week. I tested it using Eclipse 3.3.2 and it does fix the problem.
