RFR: 8047795: Collections.checkedList checking bypassed by List.replaceAll
Paul Sandoz
paul.sandoz at oracle.com
Wed Jun 25 08:30:31 UTC 2014
On Jun 24, 2014, at 8:25 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>
> On Jun 24 2014, at 01:18 , Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> Additionally the javadoc is updated to inform users that a ClassCastException may result if the proposed replacement is unacceptable.
>>>
>>
>> No users will see the JavaDoc on Collections.CheckedList since it is package private, plus i think it redundant. Any such associated documentation would need to be on the public static method, and i am not sure we really need to say anything more than what is already said:
>>
>> 3388 * Any attempt to insert an element of the wrong type will result in
>> 3389 * an immediate {@link ClassCastException}. Assuming a list contains
>
> Yes, it is redundant but might be informative if a user goes to the examine the source when encountering a CCE. I can remove it if that is really preferred.
>
I don't have a strong opinion, but i feel what is written is mostly stating the obvious. The important aspect, which is implied, "fail-first" rather than "all-or-nothing" is not mentioned. It might be better to do so and contrast it with the addAll implementation (same applies to the Map.replaceAll method if you want to be consistent). No need to block the review or another round on this if you make any further changes.
>>> Note that this changeset takes the strategy of failing when the illegal value is encountered. Replacements of earlier items in the list are retained.
>>>
>>> jbsbug: https://bugs.openjdk.java.net/browse/JDK-8047795
>>> webrev: http://cr.openjdk.java.net/~mduigou/JDK-8047795/0/webrev/
>>>
>>
>> Are there existing tests for the checked Map.replaceAll (for keys and values)?
>
> Not specifically for illegal values returned by the operator. I can easily adapt the new test I added to specifically test for this case.
>
Ah, yes, it's just values.
> Updated webrev with additional Map test and Chris's suggestion is here: http://cr.openjdk.java.net/~mduigou/JDK-8047795/1/webrev/
>
+1
--
I thought the javac compiler configuration would have flagged the need for @SuppressWarnings as an error, or is that not switched on yet?
Paul.
More information about the core-libs-dev
mailing list