[
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
From:
Andrew Niefer <aniefer@xxxxxxxxxx>
To:
P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:
05/07/2009 06:22 PM
Subject:
Re: [p2-dev] Pack200 and P2 rules headaches
Sent by:
p2-dev-bounces@xxxxxxxxxxx
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
sdk.
-Andrew
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>
To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
