Re: Intention to work on Pack200 uncompressor/compressor
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.
Re: Intention to work on Pack200 uncompressor/compressor
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. 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. -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
2006/5/26, Alex Blewitt [EMAIL PROTECTED]: The only problem is that I'm building this on a Mac (primarily) That's not a problem. Probably you are lucky guy :) 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). You can try to build Harmony VMs which are provided with sources. DRLVM for example. It will be an interesting experience. 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? If it will work with Java on MacOS X then it should work on Harmony VM. -- Alexey A. Petrenko Intel Middleware Products Division
Re: Intention to work on Pack200 uncompressor/compressor
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. 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). 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.
Re: Intention to work on Pack200 uncompressor/compressor
Alex Blewitt wrote: Hi everyone, Hi Alex 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/ Great! 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. Makes sense. 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? Yep, in fact you could develop it against a set of 1.5 libraries. If you can, keep an eye on what you are using compared to what we have already got in Harmony, but ultimately you can use any 1.5 APIs and we will be filling in behind you. 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 :-) Yep, feel free to contribute the code before it is hooked in to the j.u.jar APIs and we can be merging it and compiling it as we go. 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). That should be relatively easy, since I expect your work will primarily be in a given package or two, and we can figure out your imports when you are done. 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. If there are any internal-APIs that you expect to be useful outside the ARCHIVE module (i.e. outside j.u.jar / j.u.zip) then define them in org.apache.harmony.archive.pack200. You can go nuts with any implementation details in package (or multiple packages prefixed with) org.apache.harmony.archive.internal.pack200. Regards, Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
Geir Magnusson Jr wrote: Jimmy, Jing Lv wrote: 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. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. The license I get to by following the URL above states (amongst other things): This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Regards, Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
On 26/05/06, Tim Ellison [EMAIL PROTECTED] wrote: The license I get to by following the URL above states (amongst other things): This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? I wasn't sure about that either (which is why I posted the URL). However, I can't find any other specification for the pack200 other than this one -- and the JavaDoc for Pack200 pointed me in this direction in the first place: http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/Pack200.html Transforms a JAR file to or from a packed stream in Pack200 format. Please refer to Network Trasfer Format JSR 200 Specification at http://jcp.org/aboutJava/communityprocess/review/jsr200/index.html; Does this mean that we can't implement Pack200 by this specification, and if so, does that prevent a complete Java 1.5 library from being built? Or does it mean that I can't implement it from this specification, but I can discuss how to build a pack200 compliant algorithm for others to work from? Alex.
Re: Intention to work on Pack200 uncompressor/compressor
Excellente :-) I shall get started on it straight away ... On 26/05/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: See my other note. It's fine - we can build an implementation. geir
Re: Intention to work on Pack200 uncompressor/compressor
Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Jimmy, Jing Lv wrote: 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. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. The license I get to by following the URL above states (amongst other things): This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Alex gave us the link to the Proposed Final Draft, which isn't licensed for implementation, not the final spec itself. That can be found here http://jcp.org/aboutJava/communityprocess/final/jsr200/index.html and is under the usual spec license (which I can probably repeat by heart at this point). Ah yes, that license reads much better. My question though is not about this, but if it's part of the Java SE 5 spec and therefore would be tested w/ the Java SE 5 TCK. I guess I can go dig into the documentation around JSE 5. I'm guessing not, and therefore we'll need the standalone TCK for JSR 200. It is -- there is a java.util.jar.Pack200 type in Java 5 SE, that references the JSR200 spec for details. All systems go. Tim -- 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]
Re: Intention to work on Pack200 uncompressor/compressor
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Jimmy, Jing Lv wrote: 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. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. The license I get to by following the URL above states (amongst other things): This license includes the right to discuss the Specification (including the right to provide limited excerpts of text to the extent relevant to the point[s] under discussion) with other licensees (under this or a substantially similar version of this Agreement) of the Specification. Other than this limited license, you acquire no right, title or interest in or to the Specification or any other Sun intellectual property, and the Specification may only be used in accordance with the license terms set forth herein. IANAL but that doesn't appear to give us rights to implement the spec via that source? What am I missing? Alex gave us the link to the Proposed Final Draft, which isn't licensed for implementation, not the final spec itself. That can be found here http://jcp.org/aboutJava/communityprocess/final/jsr200/index.html and is under the usual spec license (which I can probably repeat by heart at this point). Ah yes, that license reads much better. My question though is not about this, but if it's part of the Java SE 5 spec and therefore would be tested w/ the Java SE 5 TCK. I guess I can go dig into the documentation around JSE 5. I'm guessing not, and therefore we'll need the standalone TCK for JSR 200. It is -- there is a java.util.jar.Pack200 type in Java 5 SE, that references the JSR200 spec for details. All systems go. Indeed. And I don't have to waste time getting the TCK either since it's in SE 5. Thanks! geir Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
Would you mind if I ask why? geir 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/ 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. 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? 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 :-) 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. Thanks, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Intention to work on Pack200 uncompressor/compressor
Please don't answer. Someone politely pointed out privately that I'm a moron. I understand now. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 5:23 PM To: harmony-dev@incubator.apache.org Subject: Re: Intention to work on Pack200 uncompressor/compressor Would you mind if I ask why? geir 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/ 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. 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? 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 :-) 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. Thanks, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Intention to work on Pack200 uncompressor/compressor
That said, if not required by the spec, we'll need the tck I'll get started on that. Geir -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thu May 25 17:45:05 2006 To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject:RE: Intention to work on Pack200 uncompressor/compressor Please don't answer. Someone politely pointed out privately that I'm a moron. I understand now. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 5:23 PM To: harmony-dev@incubator.apache.org Subject: Re: Intention to work on Pack200 uncompressor/compressor Would you mind if I ask why? geir 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/ 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. 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? 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 :-) 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. Thanks, Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
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]
Re: Intention to work on Pack200 uncompressor/compressor
Jimmy, Jing Lv wrote: 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. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. [SNIP] 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 :) Why not just write it in Java? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
