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 <[email protected]> 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
[email protected]
