harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Pack200 -- can now obtain files stored in archive
Date Tue, 20 Jun 2006 22:59:54 GMT
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.


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

View raw message