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.
> 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.ra...@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.ander...@oracle.com
