RFR: 8296935: Arrays.asList().set() with wrong types throws undocumented ArrayStoreException [v8]

[Tingjun Yuan]

On Thu, 16 Feb 2023 04:39:20 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> I've written a CSR report for this PR as below.  Could someone please help me to submit it to the JBS if it looks okay? Thank you!
>> 
>> ---
>> 
>> **Compatibility Risk:** minimum
>> 
>> **Compatibility Risk Description:** No implementation is modified
>> 
>> ## Summary
>> 
>> Document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
>> 
>> ## Problem
>> 
>> `java.util.Arrays.asList(Object...)` is a widely used method that wraps an object array into a mutable `List`.  The specification of  methods `List.set` and `ListIterator.set` indicates that implementations should throw a `ClassCastException` when the class of the specified element prevents it from being added to this list. However when an application tries to store an element that is not compatible with the backing array component type via the returned list, an `ArrayStoreException` will be thrown instead of `ClassCastException`, which violates the `List` specification.
>> 
>> ## Solution
>> 
>> Since this method is widely used, we do not change the current behavior. Instead, we document the current behavior of `java.util.Arrays.asList(Object...)` that it will throw an `ArrayStoreException` when an element of wrong type is trying to be set into the list.
>> 
>> ## Specification
>> 
>> Add the following `@apiNote` section into the `java.util.Arrays.asList` specification:
>> 
>> 
>>      * @apiNote
>>      * The {@link List} returned by this method does not conform to the
>>      * specification for {@link List#set} and {@link ListIterator#set}.
>>      * It is possible for the type parameter {@code T} of the returned list
>>      * to differ from the array's component type. This can occur, for example,
>>      * if the array argument type has been upcast from its component type:
>>      *
>>      * {@snippet :
>>      *    String[] strings = new String[1];
>>      *    List<Object> objects = Arrays.asList((Object[])strings);
>>      * }
>>      *
>>      * Writing an element into the returned list may result in an
>>      * {@link ArrayStoreException} instead of {@link ClassCastException} being
>>      * thrown if the element is incompatible with the underlying array's
>>      * component type:
>>      *
>>      * {@snippet :
>>      *    objects.set(0, Integer.valueOf(0)); // throws ArrayStoreException
>>      * }
>
> @yuantj 
> 
> The proposed change needs additional editing. In particular, the issue is not about conformance. I'd need to suggest changes that you'd apply, in order to get the text in the change to match what I'm essentially writing myself. In addition, CSR also needs quite a bit of editing, which I'd write myself anyway. Thus I don't think it's worth continuing with this PR. Thanks for your efforts, though, in raising the issue and attempting to address it.
> 
> The main point is that this isn't a spec violation, and if it were, one part of the specification can't "note" itself out of conforming to another part of the specification. The issue is really a clarification that some implementations might throw exceptions beyond those explicitly listed in the interface.

@stuart-marks Okay, I got it. Thanks for your reviewing anyway. Going to close this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12135