RFR: jsr166 jdk integration 2018-05

[David Holmes]

On 23/05/2018 4:40 PM, Martin Buchholz wrote:
> 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"""

Which is exactly the point I made in response to John's email and prior 
to Joe's.

CME is not the definitive source of knowledge on when to throw CME. You 
can throw a CME any time it's general/vague description matches your 
usecase. You're not required to throw it just because someone else 
thinks a particular usecase fits its description!

The key part of the CME spec with regard to intended use is "when such 
modification is not permissible". Granted "permissible" then becomes 
highly subjective. But to me this relates to a decision the designer - 
not user - of the data structure makes as to whether a modification will 
lead to an error condition or not, regardless of the semantic context of 
use for the data structure.

The fact there has been "misuse" of modCount modifications since JDK 8 
and no one has complained does not lead to a conclusion that therefore 
this throwing of CME is perfectly acceptable, it more likely means noone 
has run into it because they don't use their Collections that way 
anyway, and all this is a storm in a teacup from a practical development 
perspective. But the lack of consistency is the problem.

I don't think I have any cycles left for this regardless of what Stuart 
comes back with.

Cheers,
David