Community
Participate
Working Groups
From Jeff: We should consider using the pack200 from Java 6 as technically speaking the one from Java 5 is not guaranteed to work on Java6 code. Pragmatically I think it would as there are no language changes in Java 6 (that I know of) but it would be the safe thing to do. We'd need to confirm that, for example, something Java 5 (or 1.4 or...) packed with Java 6 can be unpacked correctly with the Java5 unpack.
The pack200 from Java6 is likely to have more bug fixes than the Java5 one. In any case, the pack200 spec allows for future enhancements to be made to the data stream, and the associated annotations (that aren't standard) known about by communicating the out-of-spec packing requirements along to the unpacker as part of the data stream. Furhtermore, the unpackers have to take this into account and guarantee that for any pack200 code, that the resultant unpack200 file is identical. The spec hasn't changed, so even if there were additional annotations or bytecodes, it should still be possible to translate them into a packed sequence that any unpacker can handle. PS There isn't an unpacker for 1.4; it only came in 1.5 (though you can use a 1.5 binary in a 1.4 system if both are installed on the same box).
Andrew, I would assume the version of the VM on the eclipse.org server that conditions/signs the jars should be updated as well? If this is the case, there isn't a 1.6 vm version available for the architecture of the machine running the signing process.
I believe that the pack code is actually Java code so yes, there has to be a VM for the machine. We'll have to look at conditioning/packing on a different machine.
The pack200 binaries that are compiled C programs that do the same effect as the Java library code but run without a JVM. So it should be possible to copy the pack200 binary from one Java 6 VM to another system without a Java 6 install to gain advantages from any bugfixes etc. Alex.
Please confirm that copying pack200.exe from the JRE bin dir to some other place and deleting the JRE then running pack200 works. I have tried that in the past and it worked for unpack200 but not for pack200. This may have changed so needs confirmation.
The comment in #2 still stands, there still isn't a Java 6 VM available for the architecture of the eclipse.org machine used for signing.
perhaps we need to move the signing to a different machine. At some point this will become an issue. Certainly with Java 7.
(In reply to comment #7) > perhaps we need to move the signing to a different machine. At some point this > will become an issue. Certainly with Java 7. > Are you saying an IBM e-server p5 550 POWER5-based server is not suitable for running Java applications?
If you have a Java6 implementation of pack200 then it is just fine. Otherwise, it does us little good. In actual fact, because there were no language changes in Java6 vs Java5 we are *likely* ok packing Java6 based bundles using the Java5 pack200 implementation. However, there is a risk there and when Java7 comes out that situation is almost definitely not going to fly. We will need to pack Java7 based plugins using the Java7 pack200.
http://eclipsewebmaster.blogspot.com/2007/07/going-fishing.html
Moving to general releng bucket since it depends on the appropriate libraries being installed on build.eclipse.org.
(In reply to comment #11) > Moving to general releng bucket since it depends on the appropriate libraries > being installed on build.eclipse.org. > Looks like there is an IBM JRE 6.0 for PPC/64: ibm-java-jre-6.0-0.0-linux-ppc64.tgz (60.5MB) I'm downloading it now and I'll install it on build.eclipse.org. Should I start using it to do the signing instead of 5.0?
Great! Thanks Denis. Let me know when it's installed and I'll test the signing process.
There is an issue raised in bug 211613, when the pack.gz files created by Java 6 may not be backward compatible (ie not readable by Java 5). The backward compatibility seems to be based on the presence of .class files in the bundle. Before we can switch, we will need to check if there is a way to force backwards compatibility. If not we may need to set up the jarprocessor such that only uses Java 6 for bundles that contain java 6 .class files. Even for java 6 bundles, if they are packed, they may not be unpackable by a 1.5 vm, I'm not sure if this would be a problem or not.
(In reply to comment #14) > Before we can switch I'll hold off on changing the signing process until someone prods me with a stick.
I just happened to run across this old bug, and think the best disposition is "won't fix". Not sure if the eclipse.org process still uses Java 5, but if so, I'd leave it that way until there is an actual bug or complaint specifically about that. Each project does "different things" and most use Java 6, but "low level" ones such as Orbit still use Java 5, just to make sure compatible with the "least common denominator". I'd have to check to make sure, but believe the Platform uses Java 6 to pack (but, might use Java 7). I short, there is no consistent solution.
