Replace use of std String.hashCode() with safer alternative about jackson-core HOT 3 CLOSED

Ok, some learnings:

• append/prepend of a per-map seed does not help with std JDK hashCode() (or its variations), since they fundamentally prone to cheap substring-concatenation style generation of collisions.
• length() won't either, as substring-based strings can have same length as well.

Some remaining practical alternatives include:

• Use same hash code algo as Perl, which uses shifting; downside is that this is rather slow (twice as slow) -- however, while this is true for stand-alone calculation, it might not be measurable in big picture.
• Use Adler-32 variation: this would be much faster (in fact, even marginally faster than original hashCode()!); but I need to verify that it can benefit from seed

In both cases it is important to note that per-Map seed value should make it impractical to pre-calculate collisions.

from jackson-core.

With some testing, found out that Adler-32 is not (alas!) a good alternative; number of collisions is surprisingly high.

So: with that, changes to make will be:

• For byte-based variant, add shifting, make less linear; should pretty much fix the problem
• For char-based variant, add post-shuffling, use better multiplier. Will NOT fix substring problem, just improves non-malevolent cases
• For both, add checking so that if max-collisions-length exceeds, exception thrown: assumption being that collisions may be still calculatable.

NOTE: this does NOT fix potential issue with ObjectNode; that is covered by another Issue.

from jackson-core.

On versions: fixes included in upcoming releases:

• 1.9.9 for 1.x series (not backported as previous branches are closed)
• 2.0.5 for 2.0; and 2.1.0 when 2.1 gets released.

from jackson-core.