Mailing-List: contact harmony-commits-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Message-ID: <1302587.1160794090543.JavaMail.jira@brutus>
Date: Fri, 13 Oct 2006 19:48:10 -0700 (PDT)
From: "Alex Blewitt (JIRA)" <jira@apache.org>
To: harmony-commits@incubator.apache.org
Subject: [jira] Commented: (HARMONY-599) Pack200 implementation for Harmony
 (work in progress)
In-Reply-To: <1717956.1150240409795.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/HARMONY-599?page=comments#action_12442144 ] 
            
Alex Blewitt commented on HARMONY-599:
--------------------------------------


   [[ Old comment, sent by email on Thu, 15 Jun 2006 21:01:43 +0100 ]]


Not particularly, actually. My goal was to write something that could
be used independently of Harmony, as well as within it. However, it
has been lumped in with the rest of the implementation of the
java.util.jar code, which means that if exported it can't be used as a
standalone jar. The standard Java implementation of the
java.util.jar.* packages is independent of the actual implementation
used (similar to the way that the XML parser can be replaced on the
fly by providing a different property). I was expecting that the same
would be done for the Pack200 implementation, allowing (for example)
other people to write Pack200 implementations that could be used.

The Harmony-specific glue would obviously be in this module (including
the default factory to use if none is specified) but that doesn't mean
that the default implementation has to be bundled with the API classes
too.

Alex.


> Pack200 implementation for Harmony (work in progress)
> -----------------------------------------------------
>
>                 Key: HARMONY-599
>                 URL: http://issues.apache.org/jira/browse/HARMONY-599
>             Project: Harmony
>          Issue Type: New Feature
>          Components: Contributions, Classlib
>            Reporter: Alex Blewitt
>         Assigned To: Tim Ellison
>            Priority: Minor
>         Attachments: pack200.impl.zip
>
>
> This is the first part of the pack200 implementation. It includes code for decoding a sequence of values from an input stream (though s=2 codes are not yet supported) and can parse the constant pool headers out of an archive. Although the values make sense from introspecting the output, there are some significant things missing so far (other than the remainder of the archive format)
> * s=2 decodings are not supported, largely because I don't have any test data to show what the values should be
> * the attributeDefinitionLayout affects the default codec that is used for each band. Currently, only the default band codec is known; if this contains any vlaues, the parser won't work
> * I'm not sure if some of the index values are supposed to be 1-indexed instead of 0-indexed, such that cp[0] == null/0. I suspect that a zero value transmitted means something specific.
> * The test code looks for HelloWorld.pack, which is a packed Jar of the HelloWorld.class. Currently, I don't assert any values from it, just that it parses (or not) as well as hand-inspecting the values. A better test class with known values that can be asserted (or a family of them) will be better
> * The input stream passed to the parse method must be buffered and GUnzipped before use. Although pack files may be optionally post-compressed with GZip (most are) there isn't any mechanism to peek the values
> of the header to determine whether or not they're valid.
> Given that it's incomplete, it doesn't implement/provide the standard java.util.jar Pack200 interfaces yet.
> This has been built with Eclipse on a Mac(Java 5) so I hope that the classes are referenceable inside harmony. I've attached my .classpath and .project along with it if necessary. I hope that someone can create an appropriate classlib location, and I can then sync this with SVN to provide patches.
> I've not done all the documentation, but I've done most of the important bits (with the exception of the cpUTF8 parsing in Segment). Any patches to documentation welcome -- or even proof reading :-)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira