RFR: jsr166 jdk integration 2018-05

[Martin Buchholz]

On Tue, May 22, 2018 at 3:41 PM, joe darcy <joe.darcy at oracle.com> wrote:

>
> 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 of exception classes are (naturally) more general and vague
than the specification of concrete classes and methods that throw them.
The spec for  ConcurrentModificationException does not mention the concept
of "structural modification" but e.g. the spec for Vector states
"""if the vector is structurally modified at any time after the iterator is
created"""