RFR JDK-8029689: (spec) Reader.read(char[], int, int) throws unspecified IndexOutOfBoundsException

David Holmes david.holmes at oracle.com
Tue Apr 21 02:00:02 UTC 2015


On 21/04/2015 1:24 AM, Chris Hegarty wrote:
>
> On 20/04/15 16:17, Lance Andersen wrote:
>> Hi Pavel,
>>
>> So we are just documenting/clarifying the current behavior from what I
>> can tell from the change?
>
> Looking at the testcase, it passes with the current JDK 9 ( and 8 ), so
> this is just documenting existing behavior.

Right. The assumption is that original authors overlooked the fact that 
the @exception/@throws for unchecked exceptions would not automatically 
be inherited by subclasses, and that in fact those subclasses (in this 
case) should indeed have inherited the same preconditions from the parent.

David

>  > If so, this looks OK assuming you have an approved CCC?  The test
> seems fine.
>
> A CCC will be needed, and should be submitted after successful review.
>
>> I am assuming there should not be any issues here but would be good to
>> hear from others on this change as well
>
> Right. We do this ( clarify spec from existing behavior) in other areas
> too.
>
> Given that this is the current behavior of existing platform subtypes,
> then this change is only specifying existing behavior. Since there are
> no implementation changes, then Third party Reader subtypes will
> continue to function as before, but they may need to be updated at some
> point in the future.
>
> -Chris.
>
>> Best
>> Lance
>> On Apr 20, 2015, at 11:10 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>
>>>
>>> Hi everyone,
>>>
>>> Could you please review my change for JDK-8029689
>>>
>>> http://cr.openjdk.java.net/~prappo/8029689/webrev.00/
>>>
>>> -------------------------------------------------------------------------------
>>>
>>> There is a long-standing issue when platform implementations of
>>> java.io.Reader
>>> throw IndexOutOfBoundsException for bounds checks from inherited
>>> java.io.Reader.read(char[], int, int) method though java.io.Reader
>>> itself does
>>> not specify this situation.
>>>
>>> Suggested solution is to update the contract of
>>> java.io.Reader.read(char[], int,
>>> int) and its publicly exported descendants to capture the implied
>>> preconditions
>>> for reading range and the array size.
>>>
>>> Given that throwing IOBE in this situation is a de facto standard,
>>> this change
>>> won't bring any kind of incompatibility, though to stay compliant 3rd
>>> party
>>> implementations may need to be updated.
>>>
>>> -Pavel
>>>
>>
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>



More information about the core-libs-dev mailing list