You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Tim Ellison (JIRA)" <ji...@apache.org> on 2009/10/03 11:32:23 UTC

[jira] Assigned: (HARMONY-6346) Several archive bugfixes and optimizations

     [ https://issues.apache.org/jira/browse/HARMONY-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tim Ellison reassigned HARMONY-6346:
------------------------------------

    Assignee: Tim Ellison

> Several archive bugfixes and optimizations
> ------------------------------------------
>
>                 Key: HARMONY-6346
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6346
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: SVN Revision: 820775
>            Reporter: Jesse Wilson
>            Assignee: Tim Ellison
>            Priority: Minor
>         Attachments: archive_from_android.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> The attached patch includes several miscellaneous bugfixes, optimizations and simplifications that we created for Android's copy of the archive module.  Here's an overview of what's changed:
> InflaterInputStream
>   Removes a bogus magic number check. Previously I submitted a patch to get this check to work; but the whole premise is flawed. To demonstrate, attempt to inflate data that was deflated using non-default settings.
> InflaterInputStream, ZipInputStream, GZIPInputStream
>   These now make sure that available() returns 0 when the end of the stream is reached. Previously available() could return 1 even if read() was guaranteed to return -1.
> GZIPOutputStream
>   Slight performance fix: cast from long to int only once
> JarFile
>   Verifies the entry when the last byte is returned. This is similar to the available() problem in ZipInputStream etc.
>   Move getMetaEntriesImpl() from native to Java.
> ZipFile
>   Limit the amount of memory used while reading files. Previously we would create arbitrarily large buffers.
>   Move several methods from native to Java.
> MsgHelp
>   Keep resource bundles in memory with soft references
>   Use the system classloader always.
> Tests
>   New tests to demonstrate problems above, recovery on broken manifests, verification of empty entries
> Note that there are some problems with the patch, so it should not be applied! I will to upload an improved patch early next week. I figured I'd let everyone preview the patch in its current state; the problems are minor and include removing dead code and fixing tests with invalid assumptions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.