[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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.


- thomas