Alex Blewitt wrote:
> By the way, one of the tests has a Pack200 archive with Java classes
> in it, and one of the tests attempts to unpack that archive. With the
> recent change in 415891, it's possible that this test will fail now.
Looks ok on the latest test results (for r415945).
> But then, I'm not sure whether the tests are being run ?
Yes, the tests are being run. I see the following test counts:
org.apache.harmony.archive.tests.internal.pack200
CodecTest = 6
SegmentOptionstest = 1
Segmenttest = 1
Regards,
Tim
> If not, it's
> relatively easy to replace the HelloWorld.pack with a packed Jar file
> that just contains resources (e.g. GIFs, text files) to resolve the
> problem.
>
> Alex.
>
> On 20/06/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
>> 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]
>
>
--
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]
