I am not sure if I am using murmur3 (OpenHFT's zero-allocation-hashing) function correctly but the result seems different for hashChars() and hashBytes()
// Using zero-allocation-hashing 0.16
String input = "abc123";
System.out.println(LongHashFunction.murmur_3().hashChars(input));
System.out.println(LongHashFunction.murmur_3().hashBytes(input.getBytes(StandardCharsets.UTF_8)));
Output:
-4878457159164508227
-7432123028918728600
The latter one produces the same output as Guava lib.
Which function should be used for String inputs?
Shouldn't both functions produce the same result?
Update:
How can I get same output as :
Hashing.murmur3_128().newHasher().putString(input, Charsets.UTF_8).hash().asLong();
Hashing.murmur3_128().newHasher().putString(input, Charsets.UTF_8).hash().toString()
using zero-allocation-hashing lib which seems to be faster than Guava
Your assumption regarding
UTF-8is not correct, it holds forStandardCharsets.UTF_16LE.gives:
Additional Answer
For the desired:
this:
seems to work (please test more!)
The (hex) string conversion is sort of a problem, since the guava hash creates (really) 128 bits (16 bytes, 2 longs), whereas "your lib" gives us only 64 bits!
Half of the digits i can reproduce with: ...thx to:
With your help (sorry first time encounter this lib), I could finally:
where: