[classlib][archive] JarFile#getInputStream() (was: Re: [testing] M12 testing on Windows x86)

[Tim Ellison <t....@gmail.com>]

On 30/Nov/2009 06:31, enh wrote:
> On Sun, Nov 29, 2009 at 22:27, Jesse Wilson <je...@google.com> wrote:
>> On Thu, Nov 26, 2009 at 10:44 AM, Tim Ellison <t....@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

Re: [classlib][archive] JarFile#getInputStream()

[Tim Ellison <t....@gmail.com>]

On 30/Nov/2009 16:54, Jesse Wilson wrote:
> On Mon, Nov 30, 2009 at 2:08 AM, Tim Ellison <t....@gmail.com> wrote:
> 
>> 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.
> 
> Yup. And if we want to do likewise, we should change he *runtime* type of
> the returned stream so that it isn't a subtype of ZipInputStream.

Right, if you see my patch on HARMONY-6394 I have defined it as
ZipInflaterInputStream extends InflaterInputStream (extends
FilterInputStream extends InputStream extends Object).

>> 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.
> 
> You're right. Sadly this bogus pattern is quite common.
>   http://www.google.com/codesearch?hl=en&start=10&sa=N&q=new
> \+byte\[\w%2B\.available\(\)\]+file:\.java

:-(

Regards,
Tim

Re: [classlib][archive] JarFile#getInputStream() (was: Re: [testing] M12 testing on Windows x86)

[Jesse Wilson <je...@google.com>]

On Mon, Nov 30, 2009 at 2:08 AM, Tim Ellison <t....@gmail.com> wrote:

> 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.
>

Yup. And if we want to do likewise, we should change he *runtime* type of
the returned stream so that it isn't a subtype of ZipInputStream.



> 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.
>

You're right. Sadly this bogus pattern is quite common.
  http://www.google.com/codesearch?hl=en&start=10&sa=N&q=new
\+byte\[\w%2B\.available\(\)\]+file:\.java