harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [classlib][archive] JarFile#getInputStream() (was: Re: [testing] M12 testing on Windows x86)
Date Mon, 30 Nov 2009 10:08:45 GMT
On 30/Nov/2009 06:31, enh wrote:
> On Sun, Nov 29, 2009 at 22:27, Jesse Wilson <jessewilson@google.com> wrote:
>> On Thu, Nov 26, 2009 at 10:44 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>
>>> I know the arguments that say available() should not be used to judge
>>> the total number of bytes that can be read, but it seems that a number
>>> of applications (including our generated parser?) use it in this way.
>>>
>> And if we return a subclass of ZipInputStream (which we do) we need to honor
>> the contract of InputStream.available(), which promises to return 1 or 0...
> 
> s/InputStream/ZipInputStream/


Jesse snipped out too much context here, because my example was
...
InputStream is = jar.getInputStream(ze);
...

The method JarFile#getInputStream(ZipEntry) is spec'd to return an
InputStream, not a ZipInputStream.

Furthermore, as I showed, the RI returns a stream that answers with
available() > 1, i.e. it follows the InputStream spec.

We should follow the spec and RI behavior.  While we have only got
examples of our own code making the assumption on available() [1] I
expect that there will be third-party applications making the same
assumptions.

[1] As I have maintained, we should remove calls to available() and use
the readFully helper, which I will move into LUNI and use once the
milestone is declared.  Thanks Elliott for HARMONY-6393.

Regards,
Tim

Mime
View raw message