harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: Intention to work on Pack200 uncompressor/compressor
Date Fri, 26 May 2006 03:14:46 GMT
> 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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message