harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Date Tue, 15 Aug 2006 03:12:39 GMT


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: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message