On 29/05/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
> Alex Blewitt wrote:
>
> 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.
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. :)
There are pros and cons with implementing it in C. The pro that you
cite (that it may be faster) doesn't outweigh the con (that you then
have to compile it for each platform). Eclipse runs on many operating
systems, and having to maintain a native build for each could be quite
a challenge :-)
That said, there's no reason why a native executable can't exist, and
defer to a Java implementation (as the Javac tool does or JavaDoc, for
example). That way, you'd still be able to run it outside of Java and
be able to ship it as a pure Java file.
The algorithm was designed to be implemented in C (I believe that
Sun's currently is) so it should still be possible to implement it
that way. But bear in mind that the pack/unpack algorithm was designed
to run out-of-VM rather than in-VM because they'd assumed that you'd
want to pack/unpack once, and run multiple times. So I'm not sure that
speed is much of an issue.
Having said all that, it would be good to compare notes as both the
Java and C implementations progress, so that we can check what's
happening with relation to the spec :-)
Alex.
