Tim, I have completed changes [1] based on your ideas of using ByteArrayInputStream child for exposing its underlying buffer as well as fixed few of my earlier TODO comments. I found the contract of the underlying buffer capturing close to ByteBuffer.wrap() method and named the class correspondingly.
As for your question about IOException during manifest parsing, known data shows that RI uses the exception when Manifest cannot be either parsed or read. For example, this exception is used when line breaks violate the required pattern.I have not thoroughly tested that though, and will do it when get more time. Thanks. [1] http://issues.apache.org/jira/browse/HARMONY-4569 On Tue, Mar 18, 2008 at 2:13 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Alexei Fedotov wrote: > > I was thinking about delaying parsing of Manifest entries to get even > > more speed up while merging Tim's inlinable ByteStream (it is called > > ByteSnapshot now) and faced a design choice. Manifest#getEntries() is > > not reported to throw IOException. It means that if I delay parsing > > entries till this call and get a parse error, I can no longer throw > > conventional IOException. > > Although you are deferring the parsing, I assume you throw an > IOException if the manifest stream is not readable? > > > > What should I do? > > 1. Throw new RuntimeException > > 2. Set all entries to null (and probably get NPE very soon) > > 3. Ignore a particular attribute (name: value) with a parsing error as > > specification might be suggesting [1] > > 4. Parse entries during read() method / constructor invocation as RI does. > > What does the RI do if the manifest is readable, but not parsable? Does > it throw an IOException? > > Regards, > Tim > > > > > Suggestions? > > > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html, search for > > "Attributes which are not understood are ignored." > > -- With best regards, Alexei
