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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > Can you point out the painful bits (line numbers, etc)? > > > > > > > > > On Feb 13, 2008 11:01 AM, Alexei Fedotov <[EMAIL PROTECTED]> 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
