I've jumped ahead a bit on the pack200 archive, and written the unpacking for file data stored in a pack200 archive. The current implementation will barf if the file size is > 2Gb, because I'm pulling all the data into a byte array at present (it's pretty memory hungry anyway).
I've not got any output mechanisms coded yet, but performing a Segment.parse(in) on a pack200 will return you a Segment, and from there you can get the file_bits to reconstitute the data files. Should be relatively easy to export those into an appropriate output format at a later stage. If there's any classes in the pack file at the moment, it will fall over -- but that's because the format is organised as [constant pool, class/bytecode stuff, file data]. So if there'sno class/bytecode stuff, it just falls through to the file data afterwards. Obviously this isn't a particularly likely scenario (unless source files are stored in a Zip and then packed?) but at least it shows it's on the right track. The prior caveats still apply; it only works for un-Gzipped pack files (i.e. those created with --no-gzip) and there's no reconstitution of the goods at the other end. I'll probably spend some time on decoding the bytecode in the near future, but that will take some time. In other news, there was interest in getting the pack200 stuff under a dual licence so that it could be included in the Gnu Classpath libs too ... I'm open to that idea, as long as forking doesn't become an issue. I've also put some notes together in OPML as to the ordering of bands in a pack200 file in a separate harmony bug; not sure if it will make it into the SVN tree in a suitable location. I'd also like to suggest that we try to move the pack200 code out of the archive module into its own dedicated archive-pack200 module. If this code is to be reused in other environments (whether part of a classlib/J2SE implementation, or as a library/driver for other VMs) then it would be a good idea to separate out the implementation from the Java interfaces. After all, the standard Sun VM allows you to switch to a different pack200 provider using the java.util.jar.Pack200.Unpacker system property. It would probably not make sense for a provider to also have the remainder of the java.util.jar classes in there. Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
