Jimmy, Jing Lv wrote: >> Alex Blewitt wrote: >> On 26/05/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
