David M Williams
2015-04-11 06:48:01 UTC
I wanted to let everyone know that "we" are changing the version of Java's
pack200 at the infrastructure service I call "batch signer". (Bug 463510)
It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.
This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.
While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)
The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.
Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.
pack200 at the infrastructure service I call "batch signer". (Bug 463510)
It was using Java 6 level of pack200, and we have moved to the Java 8
level of pack200.
This command is described at
https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29
This does not directly impact Tycho users or Buckminster users (which do
their own re-pack and pack, based on the VM the build is running, I
assume) but might effect PDE users, which traditionally have used this
service to "re-pack" (condition) and sign jars -- and, then at some short
later time are "packed". At that "some later time", it is the release
engineers responsibility to use the same version to 'pack' as was used to
'repack'.
While no direct impact to Tycho or Buckminster builders, the principles
and consequences of moving from one level (Java 6) to another (Java 8)
apply with any builder, so the following points may be useful information
to all.
If you have "old byte codes", or, even new ones, compiled at the Java 4,
Java 5, or Java 6 level, you *might* find some of those bytes codes no
longer survive the "re-pack", sign, and "pack" process (where as maybe the
would survived, when using Java 6 to run your build (and hence your
repack/pack). That is, if user tries to download the pack.gz file, and
unpack into a normal jar, it may be reported to have in "invalid
signature" or in some other way "broken".
In my experience, with Orbit jars, the "error rate" is about 1.7%. Others,
for some unknown reason, see higher rates (such as 20-30%?) . Some of
these cases *might* be bugs in the pack/unpack programs, but it's just as
likely that there are "bugs" (fringe cases) where the byte codes for lower
levels of Java are not quite "right". All I know for sure: it has never
been perfect.
But, luckily, easy to solve.
All three builders (PDE, Tycho, and Buckminster) allow you to specify an
'eclipse.inf' file in the META-INF directory, with a directive (line) that
is:
jarprocessor.exclude.pack=true
Thus, that one problematic jar is not packed, but is still signed.
So important point 1: be sure you "pack200" with the same version you used
to do "repack" (if the builder doesn't do it for you automatically).
Important point 2: I wouldn't recommend studying the byte codes and trying
to find a pattern of code that is the cause (unless you just happen to
love byte codes), ... just slap in an eclipse.inf file and move on to more
important things.
Important point 3: You should not, ever never, "re-sign" and certainly not
re-pack or pack200 a jar that has already been signed or processed by
pack200. That pretty much guarantees the jar will be broken. In more ways
than one. (Bug 461669)
The reason for making this move, now, is that it is best to "keep up" with
what our users are using, and, with versions of Java that are expected to
stay in service for a while ... otherwise, we might have to monkey around
with this during a service release, which is less than ideal.
* Bonus, for reading this far in my wordy note: Why jump two levels, from
6 to 8, why not move to Java 7 first? Well it turns out, at the moment,
the versions of pack200 and unpack200 that ship with Java 7 and Java 8 are
exactly the same. But, the advantage is, in some service release, there
might be a new version and we'd pick it up automatically, as long as we
use /shared/common/jdk1.8.0_x86-latest consistently. Double bonus:
remember that pack200 and unpack200 have little to do with Java source
code they are stand-alone executables, written in C-code, that simply
manipulate byte codes. Which is how p2 can let you specify any version of
pack200 you want, no mater which version of Java you are using.
Naturally, feel free to comment in Bug 463510 if any questions or concrete
problems known.