[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Pack200 and P2 rules headaches

I think I found a solution that covers all Java version specific Pack200 problems that we've encountered so far. The jarprocessor needs to follow two strict rules.

1. Only pack (or condition) jar files that contain .class files or nested jars (i.e. typically never pack source bundles and features).
2. A jar that contain nested jars but no .class files must be packed using option -E0 (effort level 0).

These two rules will ensure that no java version dependent Pack200 magic is used unless a .class file is present in the jar. -E0 means that Pack200 switches to "Copy-mode" in which case no version dependent magic is used. That's ideal for jars that contain nested jars but no .class files.

See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=275533

- thomas


John Arthorne wrote:

Yes, this is a potential problem. I think many of our packed artifacts currently require the Java 6 version of pack200 for unpacking. Another example I noticed this morning is source bundles, which don't contain any class files, are not packed in a backwards compatible way. I entered bug 275295 for this. I can't remember if there was a strong reason for using the java 6 edition of pack200 for the packing. Obviously if we packed with the java 5 edition of pack200, we wouldn't have this compatibility problem.




Thomas Hallgren <thomas@xxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

05/06/2009 12:09 PM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc

Subject
[p2-dev] Pack200 and P2 rules headaches







Pack200 has one fairly serious quirk that might have an effect on how we
want to set up rules in P2. Here's an excerpt from the docs:

"In order to maintain backward compatibility, if the input JAR-files are
solely comprised of 1.5 (or  lesser) classfiles, a 1.5 compatible pack
file is  produced.  Otherwise a 1.6 compatible pack200 file is produced."

This perhaps looks simple and clear, but there is one implication that
isn't mentioned and that is what happens when there are zero classfiles
in the jar. Zero classfiles means that Pack200 see no reason to be
backward compatible with 1.5. No big deal right? Just refrain from
packing such files. But no, we need to look deeper. Most jars that are
nested, contains zero class files in the top jar. And that's where it
has implications on P2.

Consider the following:
A.jar contains B.jar and C.jar. Both B.jar and C.jar contain class files
but A.jar does not. With our current approach, this leads to an A.jar
that, if packed by a Java 6 JRE, only can be unpacked by a Java 6 JRE.
The fact that all .class files are Java 1.5 compatible doesn't help. So
what can we do?

Let's assume that we only pack jars that contain .class files. This
would mean that we get A.jar that now contains B.jar.pack.gz and
C.jar.pack.gz. This doesn't work very well, since P2 now only sees the
A.jar. It doesn't know that it contains nested jars that needs to be
unpacked. We cannot call the jar A.jar.pack.gz either since P2 then
assumes that it's packed. What we end up with is a container with packed
material that cannot itself be packed. How do we solve that?

A workaround for the problem would be to add a dummy 1.5 compliant
.class file when this situation occurs. The unpacker could remove it so
it would never become visible.

Thoughts?

- thomas

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/p2-dev