Gregory Shimansky wrote:
> On Monday 14 August 2006 23:37 Geir Magnusson Jr wrote:
>>> I've written a test [1] myself and cannot say I completely understand the
>>> result. With length = 0 RI 1.5 allows calling to Get<type>ArrayRegion
>>> with start equal to array length but throws AIOOBE if start is greater
>>> than array length.
>> That makes sense to me, only because I am thinking of j.i.OutputStream's
>> write([], int, int) method, which does state that it's ok if start + len
>> == arraylen...
>
> It is not specified either, is it? I looked at the
> ObjectOutputStream.write(byte[], int, int) and didn't find any detailed
> description about allowed ranges.
I looked at java.io.OutputStream write() and it was clear (to me anyway...)
>
>> I'm sure if we thought about it, we'd figure out that it lends itself
>> nicely to some common loop idiom. I suspect it will be some end case
>> when some read returns an empty buffer, so
>>
>> write(buf, 0, 0)
>>
>> works without a check, or some situation where there's some post
>> decrement leading you to
>>
>> write(buf, length, len)
>>
>> where the len was calculated from (buf.length - length) or something.
>>
>> Now, that isn't what the JNI spec says, but it seems like the JNI spec
>> was written in a hurry... :)
>
> JNI spec is indeed quite incomplete when it comes to border cases. Sun
> wouldn't need to create a special book [1] (however this clarification
> doesn't clarify this particular case) for JNI clarification if they wrote a
> complete spec from the start.
>
> However Sun usually changes a spec if its implementation doesn't work
> according to it for some time. JNI spec is really old, it was written for 1.1
>
> and the statement about exception still remains.
Yah, but like I said, it's a reasonable change, and it's consistent w/
the RI...
>
>>> I am unsure if we want to allow this compatibility and a reason to allow
>>> it. When length is 0 the application still gets nothing except for clear
>>> exception status. There is no value in allowing this call except for
>>> allowing software which has a bug in it to work. On the other hand
>>> allowing start == length to pass violates the spec IMHO.
>>>
>>> I think it is better if software which uses this undocumented feature was
>>> fixed instead of introducing this workaround, so if others agree I think
>>> HARMONY-1156 could be closed.
>> Well, I don't feel strongly either way, but am uncomfortable with the
>> inconsistency. The JNI docs seem pretty sparse, and clearly some
>> thought went into allowing :
>>
>> write( buff, buff.length, 0)
>
> The whole exception condition looks like this
>
> jsize length = GetArrayLength(env, array);
> jsize end = start + len;
> if(start < 0 || start >= length || end < 0 || end > length) {
> char msg[30];
> sprintf(msg, "%d..%d", start, end);
> ThrowNew_Quick(env, "java/lang/ArrayIndexOutOfBoundsException", msg);
> return;
> }
>
> and it is easy to change start >= length to start > length if you ask for it.
but that's not right -
a) if you believe that we should be like OutputStream, if start ==
length and len == 0 you should be ok
b) if not, then start == length is wrong as it's not a valid value
> I am still unsure if this is a place where spec should step away from the
> spec be it imcomplete or not. Programmers who don't work for Sun read public
> spec, don't they?
>
> [1] http://java.sun.com/docs/books/jni/html/jniTOC.html
>
Who uses JNI? :)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
