com.koloboke.compile

Annotation Type ConcurrentModificationUnchecked

@Retention(value=SOURCE)
 @Target(value=TYPE)
public @interface ConcurrentModificationUnchecked

Specifies that a Koloboke Compile-generated implementation of the annotated Set- or Map-like class or interface shouldn't try to identify concurrent structural modifications in returned Iterators, Cursors and during bulk operations. If a @KolobokeSet- or @KolobokeMap-annotated type is not annotated with @ConcurrentModificationUnchecked, i. e. by default, Koloboke Compile generates an implementation that does try to identify concurrent structural modifications (except through the iterator's or cursor's own remove() method) and throws a ConcurrentModificationException if it spots such a modification, just like HashSet or HashMap (see "fail-fast" sections in the specifications of these classes). If the implemented type is annotated with @ConcurrentModificationUnchecked, Koloboke Compile generates an implementation that doesn't perform any checks aimed to identify concurrent modifications.

Note that the fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Koloboke Compile-generated implementations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs. This is the reason why there is not such annotation as "ConcurrentModificationChecked" in Koloboke Compile: it is impossible to guarantee that all concurrent modifications will be spotted.

Concurrent modification checks help to identify not only (and not mainly) concurrent unsynchronized to the map or set instance from different thread, but primarily erroneous usage of iterators, cursors and bulk operations (like forEach(), removeIf(), replaceAll()), when the iterated collection or map is modified in the loop not via iterator's or cursor's own methods, or in the body of the lambda, passed into the bulk operation. So even if there is a confidence that instances of the implementation of the annotated type won't be accessed from multiple threads, it is strongly recommended not to disable concurrent modification checks if any usage of iteration or bulk operations accepting lambdas on set or map instances (or map's collection views) is planned. Keeping concurrent modification checks prevents bugs that occur really often.