RFR JDK-8029689: (spec) Reader.read(char, int, int) throws unspecified IndexOutOfBoundsException
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.
> > 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
> 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.
>> 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
>>> There is a long-standing issue when platform implementations of
>>> 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
>>> 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
>>> implementations may need to be updated.
>> 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