harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [classlib][archive] java.util.jar specialists/authors wanted to clarify manifest chunks
Date Sun, 17 Feb 2008 13:46:57 GMT
Thanks Tim for taking care of the patch! I got another question about
this module. Accoroding to specification, attributes of individual
entry sections for the same entry name should be merged. Which bytes
should be checked for a digital digest of this merged entry?

Thanks!

On Feb 15, 2008 3:52 PM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Hello folks,
>
> Alexey Zakharov kindly shared a hint with me that shorter letters have
> a better chance of being read. That is why I prepared a shorter letter
> asking again about manifest encodings in a form of patch, see
> HARMONY-5517.
>
> I really appreciate if people who touched the code before me (Nathan,
> Tim, or Evgeniya) would take a look.
> Thank you in advance.
>
> [1] http://issues.apache.org/jira/browse/HARMONY-5517
>
>
> On Thu, Feb 14, 2008 at 2:15 PM, Alexei Fedotov
>
> <alexei.fedotov@gmail.com> wrote:
> > Hello, Nathan,
> >  Thanks for your interest. I'm trying to resolve a performance problem
> >  described at HARMONY-4569. Gregory mentions that methods write() from
> >  nextChunk() are called too many times, see lines 187, 201 of
> >  working_classlib/modules/archive/src/main/java/java/util/jar/InitManifest.java
> >  This slows down Harmony VM in debug and interpreter modes and may
> >  affect overall Eclipse startup since many jars are read in the
> >  process. I'm trying to collect more data.
> >
> >  As far as I was able to advance reviewing the complex code it seemed
> >  that either code or my understanding may be improved.
> >   * "chunks" hash table is used only for jar verification. Do we need
> >  to initialize it for any manifest when this cost us much invocations?
> >  Instead of using write() methods for creating chunks one may think of
> >  remembering chunk positions in the stream, which should be read into
> >  byte array using big buffers instead of individual writes.
> >   * It seems that manifests longer than 1024 characters may result in
> >  "string too long" exception - the buffer they are read in just gets as
> >  much characters from stream as possible, and reports error if the
> >  stream is not read fully.
> >   * I don't know a reason why manifests are read in different
> >  encodings. The spec [1] mentions UTF-8 only. Nice to know.
> >   * Close functionality of readLines and nextChunk containing long
> >  conditional sequences may be rewritten in more transparent and
> >  documented way. Generally idea behind "rewriting" of chunks is above
> >  of my understanding: I have not noticed in the specification that line
> >  breaks or anything else should be "rewritten" using eight-if algorithm
> >  instead of taken as is. BTW, I have noticed that Tim was behind
> >  readability improvements of the code. I wonder what was there before
> >  and will check it after lunch.
> >   * The whole class InitManifest seems to be redundant and may be
> >  replaced with a set of static methods. It seems that specific
> >  functionality for two calls to InitManifest should be kept in the
> >  place where InitManifest is called rather than passed to InitManifest
> >  as a parameter for internal check.
> >
> >  I appreciate your comments and help.
> >
> >  [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
> >
> >
> >
> >  On Feb 14, 2008 6:00 AM, Nathan Beyer <ndbeyer@apache.org> wrote:
> >  > Can you point out the painful bits (line numbers, etc)?
> >  >
> >  >
> >  > On Feb 13, 2008 11:01 AM, Alexei Fedotov <alexei.fedotov@gmail.com>
wrote:
> >  > > Hello folks,
> >  > >
> >  > > Do we have original
> >  > > working_classlib/modules/archive/src/main/java/java/util/jar/ module
> >  > > contributors on board? Could anyone clarify the reasons behind heavy
> >  > > solution to copy manifest chunks into a separate hash table descried
> >  > > at HARMONY-4569? Aren't entity hash table the only object which should
> >  > > be populated?
> >  > >
> >  > > --
> >  > > With best regards,
> >  > > Alexei
> >  > >
> >  > > [1] http://issues.apache.org/jira/browse/HARMONY-4569
> >  > >
> >  >
> >
> >
> >
> >  --
> >  With best regards,
> >  Alexei
> >
>
>
>
> --
> With best regards,
> Alexei
>



-- 
With best regards,
Alexei

Mime
View raw message