> On 29 Dec 2019, at 18:39, Gary Gregory <garydgreg...@gmail.com> wrote:
>
> It depends on the platform you are using, which is the bug. What is most
> important WRT compatibility is the API signature's binary compatibility
> which would be maintained.
>
> As the code is now, a result value is effectively meaningless without
> knowing the "file.encoding" at the time the value was generated. There is
> no way to know this of course.
I agree that the methods with a String are basically useless. This is why I
marked all the methods accepting a String as deprecated with a note to use the
byte[] from String.getBytes(Charset) instead.
I think this is fair. The method itself saves 1 line of typing and that is just
because it uses a default seed which is non zero. Otherwise you can call:
String s;
MurmurHash3.hash128x64(s.getBytes(StandardCharsets.UTF_8));
My preference is to leave the method as dead and not change its behaviour. This
maintains behavioural compatibility but lets people know that it is not a
sensible method to be using.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
