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/07 20:53:31 UTC
[jira] Updated: (HARMONY-6346) [classlib] [archive] Several archive
bugfixes and optimizations
[ https://issues.apache.org/jira/browse/HARMONY-6346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Ellison updated HARMONY-6346:
---------------------------------
Summary: [classlib] [archive] Several archive bugfixes and optimizations (was: Several archive bugfixes and optimizations)
> [classlib] [archive] 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
> Attachments: archive_from_android.patch, archive_from_android_2.patch, EmptyEntries_signed.jar
>
> 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.