Algorithm in org.displaytag.util.ParamEncoder is bogus

====
imported from sf tracker
id 990011
http://sourceforge.net/tracker/index.php?func=detail&group_id=73068&atid=536613&aid=990011
====

The algorithm used in the ParamEncoder-class produces
easily colliding keys, e.g. "option" and "answer".

If there isn't a reason to exchange hashes between
different JRE:s (let the difference be vendor or version),
why not use the hashCode() provided by
java.lang.String? The hash is cached as well, which
might help interned Strings.

If you wan't to keep the hash backwards compat, I
suggest you use a better algo, for example the one
described by Joshua Bloch (copy-paste from my patched
class):

// Joshua Bloch, Effective Java, p. 38-39
int checkSum = 17;

for (int j = 0; j < charArray.length; j++)
{
checkSum = 37 * checkSum + (int) charArray[j];
}

// keep it positive
checkSum &= 0x7fffffff;

The downside of this algo is the length of the hash, but it
may be controlled with the number 37: lower primes yeild
less length. Other option is to let less bits through the
and-mask.

Questions/comments are welcome, my mailname is villeja
and the domain is avoltus.com. Combine those =).