Hi,
Buffer Size is definitely implementation dependent.
The test should be re done so that it doesn't assume the size of the buffer.
A simple way to structure the test would be :-
- Create a Sub class of BufferedOutputStream.
- Since count and buf have protected access in
On 8/17/06, Richard Liang wrote:
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java Specification. If we can
Vijay Yellapragada wrote:
Hi,
Buffer Size is definitely implementation dependent.
The test should be re done so that it doesn't assume the size of the
buffer.
Yes. Just thinking about if there are any user applications depending on
this behavior :-)
A simple way to structure the test
Stepan Mishura wrote:
On 8/17/06, Richard Liang wrote:
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java
Hello All,
One test case tests.api.java.io.BufferedOutputStreamTest.test_write$BII
fails on RI (passes on Harmony) because the default buf size between RI
and Harmony are different. The default buf size is not specified in the
Java Specification. If we can detect what the default buf size of
I think it's implementation detail. Any default buffer size is acceptable as
long as complying with spec.
Of course, if Harmony's default size is equal with RI's by accident, it's
good. :)
So the problem is test, not implementation code. I suggest modify the test
even if we fix our default
