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:
"Indeed, FileChannelImpl.transferFromArbitraryChannel casts a long value to
an int, it gets a negative value if the long value is bigger than
Integer.MAX_VALUE"


Hi,
Thanks, Mikhail :) I read though that bug detail, but I think this is not the same thing we are talking about. That bug was caused by a long-to-integer-cast, "Integer.MAX_VALUE + 1" is a integer value that is less than zero. The evaluation of that bug says:
"...
        file.transferFrom(socket, 0, Integer.MAX_VALUE + 1);
this is not correct, it should be:
        file.transferFrom(socket, 0, (long)Integer.MAX_VALUE + 1L);
..."
And it throws IllegalArgumentException.

But in our topic, the IOException was caused by native operation. The question is, shall we modify native code/Harmony portlib to allow system-call deal with the long parameter itself, instead of dealing it in Harmony code? RI seems doing in this way.

On 7/26/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:

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 solve the problem, not cut long to a
integer in Harmony's Java or native code.
Currently the problem is that the portlib has ignored the difference
between Linux and windows, so we see no difference in Harmony, while RI
behaves differently.

And again, any sounds for TestNG? :)

>
> 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 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 silently. It is clear that the difference is
>> > caused by system call. Unfortunately Harmony fails to behave like RI
as
>> > its has the same native code using the port-lib.
>> >     If it is necessary to make Harmony behaving exactly like RI, I
>> > suggest writing native code for transforFrom. This may be a
>> > waste-of-effect as it is nearly the same except for this little
>> > difference.However, currently people have few chances to use a size
>> > larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call
does
>> > not support long value to pass in.
>> >
>> >     Another thing I'd like to mention is that it'll be great if we
can
>> > use testNG, or decide some other way to go. At least 2 testcases
should
>> > be written for different platform as I remember, including the one
for
>> > this problem. :)
>> >
>> > --
>> >
>> > 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]
>> >
>> > Dear Jimmy:
>> As spec is not clear about how to deal with the argument greater
>> than Integer.MAX_VALUE, maybe we shall look more closely at what RI
>> does and
>> how the system call behaves.
>>         I think it will be a good idea to let native code or even
system
>> call itself treat with such affairs, provided that Harmony will
>> support some
>> 64-bit  platforms one day. Thus it may be not so wise to throw some
>> exception in java code if encountering the data longer than 32-bits.
>> Besides, whether we should behaves the same as RI, even if it is
>> different on different platforms? :)
>>
>>
>>
>> --
>> Leo Li
>> China Software Development Lab, IBM
>
>


--

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]

Reply via email to