Andrew Zhang wrote:
On 7/19/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
I tried the test, and it failed as you said with RI on my WinXP. And I
also tried to pass in a read/write FileChannel got from
RandomAccessFile, the test passes.
Paulex, the test fails on my machine!
Seems RI returns 2*length instead of length.
For failure details, please refer to [1].
Oops, I meant it didn't throw exception, I didn't assert the return
value :-[ . Anyway, the fact remains: RI has different behavior for
readonly and readwrite channels.
I consider this is RI's bug, because
no way to have such different behavior in this clear test. So I think we
should follow spec.
I also suggest to report this to Sun JDK bug db as well, because I think
it is not trivial. And I don't believe Sun will at last decide, instead
to fix this, to modify the document as "the behavior is implementation
dependent if the source channel has fewer than count bytes remaining..."
;-)
Maybe it will be fixed as: "For FileChannel, the channel will be
resized to
the postion+count bytes if position+count is greater than current file
channel size. " :) Just kidding.
As our compatiblity guideline, we should comply with spec.
But will the behaviour of RI be considered as illogical? Personally I
think RI's behaviour breaks spec, and is only a bit(very limited)
logical.
Any suggestions/comments?
Thanks.
Jimmy, Jing Lv wrote:
> Hi:
>
> I find a conflict that RI does not behave as spec says in
> java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
> long position,long count).
> The spec says:"...Fewer than the requested number of bytes will be
> transferred if the source channel has fewer than count bytes
> remaining..."[1]. As expected, invoking this method with a count
> larger than the number of bytes remaining in the ReadableByteChannel,
> RI should return a number of bytes exactly transfered. But in fact, RI
> throws an IOException. I run the test[2] on windowsXP SP2 with
> RI1.5.0_01 and RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and
> RI1.5.0_06, and get the same result.
> Currently Harmony behave well on this. I guess this is a bug of
> RI, and Harmony implementation is good. If no objection, I suggest add
> this test to Harmony.
> Any opinions? Thanks!
>
>
> [1] spec of FileChannel:
>
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
>
> [2] the test:
> public void test_transferFromLReadableByteChannelJJ_overflow()
> throws Exception {
> String content = "test content";
> int length = content.length();
> File readFile = File.createTempFile("testfile1", "tmp");
> File writeFile = File.createTempFile("testfile2", "tmp");
> FileOutputStream fos = new FileOutputStream(readFile);
> try {
> fos.write(content.getBytes());
> } finally {
> fos.close();
> }
> FileChannel fc1 = new FileInputStream(readFile).getChannel();
> FileChannel fc2 = new
FileOutputStream(writeFile).getChannel();
> try {
> long result = fc2.transferFrom(fc1, 0, length * 2);
> assertEquals(length, result);
> } finally {
> fc1.close();
> fc2.close();
> }
> }
>
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[1]
junit.framework.AssertionFailedError: expected:<12> but was:<24>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:282)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:136)
at junit.framework.Assert.assertEquals(Assert.java:142)
at
com.andrew.FileChannelTest.test_transferFromLReadableByteChannelJJ_overflow2
(FileChannelTest.java:55)
... ...
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
