Alex Blewitt wrote:
Hi everyone,
I'd like to start work on an implementation of the pack200
decompression algorithm, from the specification which is available at
http://www.jcp.org/aboutJava/communityprocess/first/jsr200/
I shall give you a warm welcome for implementation of Pach200! :) But
as I know few about the legality, I wonder it is legal for us(Harmony
developers) to read such algorithm directly from jcp.org? Can anyone
give an answer? Let's go ahead if there's no obstacle.
The actual java class/interface is relatively simple, but the
implementation behind the unpack() and pack() methods decidedly isn't
:-) My goal will be to provide the unpacking algorithm first, and then
work on a packer subsequently. I'll probably try to write it in an
o.a.h module first, and then hook it into the java.util.jar
classes/packages later.
Yes, we have a Pack200.java in java.util.jar, and can write its
implementation in a internal pachage.
According to Tim's guidance:
http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html
a naming of "org.apache.harmony.util.jar
.internal " maybe appropriate. And there's a package private factory
class PackFactory, for hooking the implementation class. You may read
them for more information for how to initialation.
The only problem is that I'm building this on a Mac (primarily) and so
I don't have the ability to download the IBM VM for bootstrapping the
VM process (though a later task is to see if I can help with the
migration of the VM to Mac OS X). Can I develop it against the Java
1.4 on my machine for the o.a.h module first, and then contribute it
in stages?
I know little about Mac, though I love its appearance :) I wonder if you
would write the implementation by pure java or native code. IMHO, write
them in native may be a help in performance, and maybe easy to merge
(And we see, RI create a excuteable pack200.exe in its jre). The code
can be put in native-src\(win.IA32/share/Linux.IA32/Mac?)
\archive, naming pack200.c or so.
BTW, I don't know if Harmony can be run on Mac currently. However, that
is an aim :)
The other problem is that the API is pretty sparse; the packer either
unpacks, or it doesn't :-) So from a contribution point of view, there
may not be much to publically show, but I'd like (if possible) to have
some of the implementation work made available as I go, in case anyone
else wants to help out :-)
You may document the interpret of the algorithm, and offer some
testcases :)
I'd also like to try and design the implementation such that it could
be downloaded and used by other OSGi implementations (e.g. Eclipse).
If someone can give me some advice as to a suitable package name I can
make an initial start on an implementation, and then in stages can
post it to Jira.
As far as I understand the algorithm, it was a little complex and may
take a period of time to implement. So good luck, and let's discuss on
mailing-list if there's something hard. :)
Thanks,
Alex.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
