Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 202.81.18.154 is neither permitted nor
 denied by domain of firepure@gmail.com)
Message-ID: <44C9A23C.60702@gmail.com>
Date: Fri, 28 Jul 2006 13:35:56 +0800
From: "Jimmy, Jing Lv" <firepure@gmail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classLib]Given a long value, RI behaves differently on windows
 and linux (and TestNG?)
References: <44C5C171.3020104@gmail.com>
	 <e66844de0607250025r613756bau122d4453327d868a@mail.gmail.com>
	 <2c9597b90607250432y5e273bffy2b7d16fdaec1992@mail.gmail.com>
	 <44C721CE.3030509@gmail.com>
 <bc79dd600607260333g178c6257pf51393921b939873@mail.gmail.com>
In-Reply-To: <bc79dd600607260333g178c6257pf51393921b939873@mail.gmail.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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 <firepure@gmail.com> 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 <liyilei1979@gmail.com>:
>> >> 2006/7/25, Jimmy, Jing Lv <firepure@gmail.com>:
>> >> >
>> >> > 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: harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail:
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >> > 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: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 
> 


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org