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