[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] Pack200 compression
|
Hi Ed,
Thanks for your reply.
I don't plan to make an executable, unless more volunteers join in.
The library will provide the ability to compress and uncompress pack200
archives, the difference is the caller will need to create the file and
perform any deflate or zip compression following pack200 compaction,
this isn't difficult, the executable is there for convenience, the
library provides the necessary functionality.
I'm currently working on adding support for the StackMapTable Attribute
and I can tell you it is difficult, other parts such as adding support
of new constant pool entry's, not so much.
I don't think we'll see as many changes to bytecodes as we seen recently.
Regards,
Peter
On 26/06/2018 3:20 PM, Ed Merks wrote:
Peter,
Sorry that no one has replied. There is not so much active work being
done on p2. Indeed pack200 is relatively important for p2 because of
course pack200 significantly reduces the size of the downloads.
Having worked a lot with p2 while implementing Oomph, I expect there
will be significant problems if p2 runs with a JRE that doesn't
include the pack200 executable.
If you look at
org.eclipse.equinox.internal.p2.jarprocessor.Utils.getPack200Commands(String)
you'll see that p2 actually uses the unpack200 executable, not some
Java library.
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.jarprocessor/src/org/eclipse/equinox/internal/p2/jarprocessor/Utils.java#n96
And in
org.eclipse.equinox.internal.p2.artifact.processors.pack200.Pack200ProcessorStep.initialize(IProvisioningAgent,
IProcessingStepDescriptor, IArtifactDescriptor) you'll see
initialization fails when pack200 is absent:
https://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.p2.artifact.repository/src/org/eclipse/equinox/internal/p2/artifact/processors/pack200/Pack200ProcessorStep.java#n44
In general, it seems a relatively daunting task to keep up with the
more rapid releases of Java in terms of maintaining pack200 support
for any changes to the byte code format.
Also note that the builds we all do at Eclipse will need to continue
to produce pack200 files for this to remain useful, so whatever is
done to support unpacking will also have to provide the support for
packing and that will need to be available in all the CBI
(Maven/Tycho) builds.
Regards,
Ed
On 24.06.2018 04:19, Peter Firmstone wrote:
As you may or may not be aware, Oracle has chosen to deprecate
Pack200 in Java 11 and removal in a later version, citing maintenance
as the reason.
I've taken the Pack200 implementation from Apache Harmony, which, at
version 150.7, is somewhat behind the latest Pack200 standard version
170.1.
Unlike the Pack200 implementation in OpenJDK that written in C++,
Harmony's is written in Java and uses ASM 3.1.
I have updated the library to ASM 6.2 and have started implementing
later Pack200 standard features.
Some of these are relatively difficult to understand, such as the
StackMapTable Attribute and other components are relatively easy to
implement.
I've also started looking at the latest JVM 10 standard, and thinking
about how to support bytecode features in that as well.
The code can be found here:
https://github.com/pfirmstone/pack200
I'd appreciate any help people can provide, since Pack200 is also
important to p2, I'd also happily donate any additional code and
participate in it's development here, if the p2 project see's value.
Regards,
Peter.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/p2-dev