Thanks for the comment. webrev has been updated accordingly. Flush class
is a quick hack to verify the
change, it needs to be auto run one if putback.
We might want to separate the proposed "incompatible" change of
DOS.flush() into a separate rfe/bug,
if we can not have a consensus if we should change the existing/default
behavior, and integrate the change
of Deflater first after we all agree on the interface. IIS.isAvailable()
definitely is a separate issue.
Sherman
Martin Buchholz wrote:
Here are review comments on your webrev
http://cr.openjdk.java.net/~sherman/zipflush/webrev
---
308 * Returns actual number of bytes of compressed data.
=>
308 * Returns actual number of bytes of compressed data written
to the output buffer.
---
{...@linke needsInput() needsInput}
=>
{...@link #needsInput()}
---
accumualte => accumulate
(yes, I know this is zlib's typo)
---
achieve the maximize => achieve the best
---
comparessed => compressed
---
358 * so far (In particular t...@link #needInput needInput}
returns {code@ true}
add missing space
code@ => @code
needInput => needsInput
---
178 public int available() throws IOException {
179 ensureOpen();
180 if (reachEOF) {
181 return 0;
182 } else {
183 if (inf.needsInput())
184 return in.available();
Even if you could deal with the compatibility problems of applications
relying on the 1/0 existing specified behavior, this code
seems wrong because an inflater might possibly shrink the input.
Maybe you can use something like deflateBounds?
---
8 if ("-client".equals(args[0]))
Confusing, because of hotspot flag with same name.
Are you trying to find a launcher bug?
How about "client" instead of "-client"?
Better yet, implement Flush as a single java program.
---
Martin
