But from the bug it follows that SUN result depends on long-to-int
convertion.
So you never know if result if positive (OK) or negative (Exception).
I vote just to do it right and to ignore buggy RI behaviour in this case.
On 7/28/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Hi,
Thanks, M
Mikhail Fursov wrote:
The comments to this bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5105464
can give us some additional thoughts.
As follows from this comment any (positive or negative) value could be if
MAX_INTEGER is passed.
So I propose not to follow RI here.
The comment:
"Ind
The comments to this bug
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5105464
can give us some additional thoughts.
As follows from this comment any (positive or negative) value could be if
MAX_INTEGER is passed.
So I propose not to follow RI here.
The comment:
"Indeed, FileChannelImpl.tr
Alexei Zakharov wrote:
Hi,
Is there any known real applications that use NIO for reading stuff
with 4GB blocks?
I've never heard of that. However, I believe there may be some in the
future, or the operation system may support this. That's the reason I
suggest Harmony use system call to solv
Hi,
Is there any known real applications that use NIO for reading stuff
with 4GB blocks?
Regards,
2006/7/25, Leo Li <[EMAIL PROTECTED]>:
2006/7/25, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
>
> Hi:
>
> I find another platform-dependent operation
> FileChannel.transforFrom(ReadableByteChannel sr
2006/7/25, Jimmy, Jing Lv <[EMAIL PROTECTED]>:
Hi:
I find another platform-dependent operation
FileChannel.transforFrom(ReadableByteChannel src, long position, long
count) in java.nio.channels. RI behaves differently if the given count
is larger than Integer.MAX_VALUE: on windows, it throws
Hi:
I find another platform-dependent operation
FileChannel.transforFrom(ReadableByteChannel src, long position, long
count) in java.nio.channels. RI behaves differently if the given count
is larger than Integer.MAX_VALUE: on windows, it throws an IOException;
on Linux, it return zero sil
