HPPCRT-37: API changes and internal code refactorings from HPPC v0.7.0

[vsonnier]

This is a meta-issue tracking what I may add in HPPC-RT from HPPC v0.7.0 master.

Already done in v0.68 and before:

HPPC-97 : Use unallocated slot marker key instead of an explicit allocation table for hash containers
HPPC-101 : All current benchmarks are JMH or ad-hoc ones.
HPPC-106 : Drop Guava adapter (and dependency)
HPPC-113 : Cleaned up API transitioning from capacity to expected elements. Already more or less HPPC-RT principle, RT has also capacity() method.
HPPC-119 : Make the default hashing strategy an intrinsic (through the generic inlining mechanism)

Added for next release:

• HPPC-115 and HPPC-103 : Return of the lost perturbation. I'll roll my own vision here with HPPCRT-35 without any customization for simplification.
• HPPC-111:Drop identity(map|set) specialization and add overrideable comparator. Easy enough by subclassing CustomHashMap, done through HPPCRT-36
• HPPC-104 : Ability to create a read-only view of a map. Consists in removing l* methods from maps and sets.
• HPPC-117: API simplifications and changes. For me, just newInstanceXXX() renamed into newInstance() with proper overrides.
• HPPC-120: Rework entry shifting routine to be less hairy
• HPPC-121: Rename remove{All|First|Last}Occurrences(key) to remove{All|First|Last}(key)
• HPPC-108: Rename IntDoubleLinkedSet to DoubleLinkedIntSet
• HPPC-125: equals should not compare with subclasses of itself.
  This was mostly already done, with some modifications: all containers with overridable criteria for equality or order are already compared against their overridable criteria. So add getClass() test instead of instanceof to prevent comparison with subclasses.
  On the other hand, all lists have an implicit order independent of the nature of elements, so finally all KTypeIndexedContainer are comparable with each other.
• HPPC-140 : Maps return a fully fledged collection from values(). Indeed, keys() and values() already returned Collections from a long time in HPPC-RT. Still, rename the retuned types from KeysContainer/ValuesContainer into KeysCollection/ValuesCollection to stress on that fact.
• HPPC-130: removeAll(KTypeLookupContainer) had an incorrect generic signature
• HPPC-131: retainAll(KTypeLookupContainer) had an incorrect generic signature
• HPPC-133: KTypeContainer.toArray(Class) can return incorrect array type
• HPPC-135: KTypeVTypeAssociativeContainer#removeAll had an incorrect generic signature
• HPPC-114: Buffer resizing and allocation should be throwing non-assertion mode exceptions. Finally add it, among lots of other little changes here and there to converge on the HPPC sources.
• HPPC-134: Set and Map's removeAll() should pick the best removal strategy.
• HPPC-141: Drop mutables (*Holder classes), but keep the IntHolder for tests.
• HPPC-145: Remove "Open" to simplify class names of hash containers.
• HPPC-146: Remove DoubleLinkedIntSet, duplicate of HPPCRT-40.
• HPPC-149: Recognize tests.seed as the initialization seed for randomized key mix strategies. Simply plug the property into Containers.randomSeed64() which generates the unique perturbation seed per-container. The only usefullness is indeed for tests, where we can actually have deterministic perturbation values.
• HPPC-152: Add XorShift128+, and replace XorShiftRandom. Make it extend Random and add next(bits) like the old XorShiftRandom so that it is also a full fledged Random class.
• HPPC-159: Add .visualizeKeyDistribution(int characters) to maps and sets, but only for tests. No need to weigh down the public API more with a thing the final user have no control of. (HPPC-RT key "randomization" is not configurable contrary to HPPC)

Won't do:

HPPC-112: Add ensureCapacity(elements) to containers.
For simplification sake, don't implement Preallocable
and only do HPPC-114 to be able to catch OMM situations.
The HPPC-RT philosophy is to use preallocated sizes if the user wants zero-garbage behaviour. The moment reallocation occurs you lost anyway, which means either your application is misbehaving, or you fucked up by not preallocating at the right size. In this case, diagnosis messages from HPPC-114 are enough.

HPPC-116 : Index - based methods to replace lget()/lslot() and so on. Let's drop the subject completely for the sake of API simplification and maintainance POV.
HPPC-139: Add release() to the API.
HPPC-143: Add KTypeScatterSet and KTypeVTypeScatterMap. For API simplicity sake, (and maintainance for the dev. POV) don't add another specialization which is only there for performance reasons.
HPPC-144: Separate esoteric container combinations into a separate JAR. Although I agree that floating point keys in hash maps do not make a lot of sense (even more for indirect floating point CustomHash !), I don't want to make another jar : So either drop them completely, or keep them as is. Either way, it is only a matter of existing Velocity directives doNotGenerateKType() to customize...

[vsonnier]

All the remaining enhancements are now treated as part of HPPCRT-39

[vsonnier]

Closed in 8fa586d

[vsonnier]

Re-open for additional fixes, whole list in first post.

[vsonnier]

HPPC v0.71 is released, this issue can be closed now.