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

I've create bug 275533 [1] to track the issue specifically for Galileo. 
See if we can all line up on Java 5 Pack200.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=275533

Andrew Niefer <aniefer@xxxxxxxxxx>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
05/07/2009 06:22 PM
Re: [p2-dev] Pack200 and P2 rules headaches
Sent by:

We should perhaps in the 3.6 time frame investigate whether apache harmony 
has a better implementation without these problems that we can ship in the 


Thomas Hallgren <thomas@xxxxxxx> 
Sent by: p2-dev-bounces@xxxxxxxxxxx 
05/07/2009 05:25 PM 

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

P2 developer discussions <p2-dev@xxxxxxxxxxx> 

Re: [p2-dev] Pack200 and P2 rules headaches

John Arthorne wrote: 

Thomas Hallgren wrote on 05/07/2009 10:05:50 AM:
> Personally, I see this as a missing part of an otherwise good tool. 
> Pack200 should have an option or something to control this. One way 
> to overcome this deficiency is to check if a file is missing .class 
> files and when that happens, change the magic. I've tried that, and 
> it seems to work just fine. 

Yes, it's really suprising that they would *default* to being incompatible 
with Java 5, but I guess that's what we're stuck with. On the other hand, 
there is very little value packing a JAR file that doesn't contain any 
class files, since the pack200 compression is strictly dealing with class 
file compression. In this case you're paying the deflate/inflate 
performance cost without any transfer improvement. 
Consider the case when you have nested jars. The top container has no 
class files, so it still defaults to Java 6. All your nested content needs 
packing though, so you cannot leave your top jar unpacked. If you do, the 
nested packs will never be discovered.

Hacking the magic seems a bit scary, in case there are any incompatible 
changes in the format we don't know about. A possible safer hack would be 
to check the magic and delete the packed file if the magic started with 
"CAFED00D/160" (gotta love those Java magic numbers). This would imply the 
file contains no class files (or pure Java 6 content, which I doubt is 
true for many Galileo bundles). 
Again, this won't work if you have nested jars. With no nesting and no 
.class files, there's really no reason to pack.

- thomas
p2-dev mailing list
p2-dev mailing list