Re: [classlib][nio]the conflict of RI and spec?
No, temp files are not controlled by OS.
2006/7/21, Jimmy, Jing Lv [EMAIL PROTECTED]:
Anton Luht wrote:
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
Ah yes, sorry for that, thanks!
So temp files may not controlled by OS itself even they are in temp
directory of OS?
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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();
}
}
--
Best Regards!
Jimmy, Jing Lv
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]
--
Best Regards!
Jimmy, Jing Lv
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]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio]the conflict of RI and spec?
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]
Re: [classlib][nio]the conflict of RI and spec?
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. 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 agree that this is RI bug. RandomAccessFile(rw) works OK because the channel is writable and can be extended by map() method. FileInputStream or RandomAccessFile(r) returns redable channel and we get 'Access Is Denied when map() tries to change its size. The description of such a process could be found here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6416884 , see item 2 in evaludation. + I examined Sun's bug database I have not found any bug like this reported before. + Note, that this test is failed even with writable source channel: the 'result' is 2*length -- Mikhail Fursov
Re: [classlib][nio]the conflict of RI and spec?
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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();
}
}
--
Best Regards!
Jimmy, Jing Lv
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]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio]the conflict of RI and spec?
Anton Luht wrote:
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
Ah yes, sorry for that, thanks!
So temp files may not controlled by OS itself even they are in temp
directory of OS?
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] 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();
}
}
--
Best Regards!
Jimmy, Jing Lv
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]
--
Best Regards!
Jimmy, Jing Lv
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]
[classlib][nio]the conflict of RI and spec?
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();
}
}
--
Best Regards!
Jimmy, Jing Lv
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]
Re: [classlib][nio]the conflict of RI and spec?
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. 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...
;-)
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]
