On 2009-02-05, Christian Grobmeier <grobme...@gmail.com> wrote: >> * ZipOutputStream contains some proteted static final byte[] >> "constants"
>> This means any subclass could modify them. Findbugs suggests to >> make the package private. Ant couldn't do that because of backwards >> incompatibility, but a sandbox component can. Should we? > I guess we can, but I think we should wait after the first release. I'm with Sebb here and would remove any part of the API that I'm uncomfortable with before the release. > At the moment I am copying Ant-codebase to here. If Ant is changing > forward I may have problems if we change such kind of stuff when > updating. You may have noticed how I merged stuff from Ant a few times over the past days and for the time being I intend to keep doing that, don't worry. The svn merges were more or less painless, the only conflict I got was in UnknownExtraField because the commons-compress version uses m_foo fields where Ant uses foo (likely because of Avalon/Peter Donald coding style). >> * ArchiveStreamFactory should do something when it fails to read >> enough bytes for the signature, but what? >> Given the original TODO comment, I stayed away from a decision. > I have not thought about that. At first glance I guess it should throw > an ArchiverException. An empty bzip2 compressed file is 14 bytes, maybe there are some formats that we want to support in the future that create even shorter outputs. I suggest we add the number of bytes actually read as a second argument to the various matches methods and will end up with no InputStream matching the file's signature instead. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
