RFR: jsr166 jdk integration 2018-05

[joe darcy]

Hi John,


On 5/19/2018 3:54 PM, John Rose wrote:
> On May 19, 2018, at 9:42 AM, Martin Buchholz <martinrb at google.com> wrote:
>> I like thinking of ArrayList as just an optimized HashMap, Lua-style, and
>> HashMap.replaceAll also does not increment modCount, supporting our
>> "structural modification" position.
>>
>> The thing that bothers me most about the status quo is the *inconsistency*
>> - between root list and subList, between default implementation and
>> concrete implementation, and between ArrayList and HashMap.  And there
>> seems to be no reason for users to expect any such inconsistency.
> FWIW my $0.02.

I'll take your $0.02 and raise you another $0.02.

Commenting on your commentary rather than on the particular merits or 
demerits of whether replaceAll should throw CME, I think a more holistic 
approach should be used to evaluate CME and replaceAll and similar issues.

The specification of CME is not sacrosanct. We can and do evolve the 
specification of types all the time, even ones that have been in the 
platform for many years. We certainly have constraints on that 
evolution  to maintain compatibility 
(https://wiki.openjdk.java.net/display/csr/Main). However, given the 
first and last sentence of the main CME javadoc:

     "This exception may be thrown by methods that have detected 
concurrent modification of an object when such modification is not 
permissible.
     ...
     ConcurrentModificationException should be used only to detect bugs."

having a CME thrown during replaceALL seems well within the general 
intended semantics of the CME exception type.

Specifications are updated for a variety of reasons. Sometimes they just 
need refinement. Sometimes our understanding of the problem space 
changes. And sometimes the needs of the platform change and the existing 
types need to be adapted.

The replaceAll methods under discussion have been coded to throw CME 
since they were introduced in JDK 8. To my knowledge, there have been no 
bugs filed complaining about this behavior.

If as stewards of the platform we conclude it is useful for replaceAll 
to throw CME, I think we should not stop ourselves from doing so on the 
mistaken belief that our use of CME cannot be evolved. I do think it is 
reasonable to have consistent use of modCount and CME in the different 
replaceAll implementations.

Cheers,

-Joe