RFR: jsr166 jdk integration 2018-05 (original) (raw)

joe darcy joe.darcy at oracle.com
Tue May 22 22:41:35 UTC 2018

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.02andraiseyouanother0.02 and raise you another 0.02andraiseyouanother0.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

More information about the core-libs-dev mailing list