harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Intention to work on Pack200 uncompressor/compressor
Date Tue, 30 May 2006 11:58:12 GMT
Jimmy, Jing Lv wrote:
>> Alex Blewitt wrote:
>> On 26/05/06, Jimmy, Jing Lv <firepure@gmail.com> wrote:
>>
>>> 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.
>>
>> I'm aiming to implement it in pure Java, because one of the other
>> goals is to allow other clients (e.g. Eclipse) to be able to bundle
>> the pack/unpack code.
>>
> 
> To tell the truth, I was interested in it and planning until something
> defers my plan. Why I planed to wrote it into native was that:
> 1. C code of such arithmetic may be faster and
> 2. Harmony may also contain a executable Pack200 as RI does.

A reasonable JIT using runtime information (profile-directed
optimizations etc) has every chance to out class a static C compiler.
Unless you envisage the need for lots of JNI crossings I suggest you
write it in Java.

In addition, there is nothing to stop us creating a command-line version
of the Java application.  There are a number of options for that too.

Regards,
Tim


> And to allow Eclipse-like clients to bundle the code, maybe you can use
> JNI to port the native codes into Java. IMHO it'll be easy.
> However I'm just suggesting, it all depends on you. :)
> 
>>> BTW, I don't know if Harmony can be run on Mac currently. However, that
>>> is an aim :)
>>
>> Yes, it certainly is :-)
>>
>>> You may document the interpret of the algorithm, and offer some
>>> testcases :)
>>
>> Actually, it would be good to have some packed Jars that I could then
>> test my unpacking algorithm on. Does anyone know if I can run the
>> Sun-supplied packer to compress Jar files and then use that as an
>> input into my unpacker algorithm? I'm guessing it's OK to do that, but
>> I need to be able to demonstrate that I've not used any internal
>> knowledge of the implementation to achieve the goal of a clean-room
>> implementation. The other alternative is for others to pack some
>> simple Jars, and then verify that the unpacking algorithm works
>> independently -- but I could use some sample 'hello world' type Jars
>> for my own testing.
>>
>>> 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. :)
>>
>> It's certainly fun :-) Most of the encodings are variable length,
>> which makes it fun for trying to run through a compressed Jar (it also
>> means that I have to complete the unpacker for the first bits before I
>> can work on unpacking the remainder).
>>
> 
> Yes, algorithm-analysis and coding are really fun, especially in such
> community like Harmony. Let's enjoy it :)
> 
>> Mind you, one neat feature (which I didn't appreciate before) is that
>> the algorithm is designed such that you can concatenate two pack200
>> files together and it's still a valid file. So you can pack a bunch of
>> Jars independently, and then concatenate them all into one big file
>> for subsequent compression/transmission.
>>
>> Alex.
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

---------------------------------------------------------------------
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