If both the default `containsValue` and the default `values` methods are
inherited by an implementating class, they will get a `StackOverflowError`
on trying to test for a value being present.
This is because the default `values().contains` calls `containsValue`, but
the default `containsValue` calls `values().contains`.
Now make the default `containsValues` loop over the entry set.
Add a comment that you should probably override this is your `values()`
has a better implementation. Same also retroactively applied to `containsKey`
and `keySet()`.
Finally, expands `AbstractInt2IntMapTest` to include the generic suite of tests
from `Int2IntMapGenericTest`, with a dummy testonly implementation that implements
the bare minimum for a mutable Int2Int map, to test as many of the `AbstractInt2IntMap`'s
default methods as possible.
Turns out, in the Java API and fastutil, there are no Itrator backed Spliterators
that actually gives the iterator to multiple splits, and thus the iterator will
never be used by multiple threads. This makes the iterator's thread safety, or
lack thereof, is a non-issue.
The overrides of spliterator where useful though, so those have been kept, just
now using fastiterator if possible.
fastIterator, with its Entry sharing nature, is _thread hostile_. Not even external
locking can make it safe for use in parallel contexts. Thus you absolutely
should not wrap them in spliterators and then make a parallel stream on them.
This change fixes spliterators that were trying to wrap the fastIterator, and instead
makes them use the non fast iterator instead for spliterators.
(Other single thread only use cases continue to use the fastIterator if present).
Also puts various "big scary warnings" in places where FastIterators can be returned
to the user.
Fix issues where not all the ways to iterate `keySet` or `values` in a
LinkedOpenHashMap would follow the proper order (instead falling back to regular OpenHashMap order).
Make sure all OpenHashMap's (and their Linked and Custom cousins) views have proper iterators and spliterators,
saving a lot of implicit casts by the generics system.
Add unit tests for all these.
Instead of newly creating an empty BigArray, now it fallsback to the default constructor.
This will allow it to have much better resizing performance, as instead of 0->1 on first
add, it will go 0->10 (because of DEFAULT_EMPTY_BIG_ARRAY being used now).
The array based of remains the same, we need to ensure the same runtime type is kept,
even if empty.
Also minor doc updates to ArrayList as well.
According to BigArrays.equals, this is faster then the traditional
forwards loop for big arrays, at least in OpenJDK 8 and below (with Java 8 being our target version).
This is much clearer that we mean the types that use `==` for equality
testing instead of `.equals`, and not confuse it with `KEYS_REFERENCE`
macro which means any types using Object backed members.
Also documents the gotcha of trying to use a Reference based and a
non-Reference based type together (e.g. you may get non symmetric `equals`)
Also does the same for VALUE.
Currently ImmutableList.subList doesn't return an ImmutableList itself
due to the current implementation of ImmutableList being closely tied to
the idea the full array is the whole list.
This may change in a future release.
