The two murmur hash classes call String#getBytes() instead of String#getBytes(Charset|String).
This means you can get different results depending on where in the world you run the code or by changing the "file.encoding" system property. I can't imagine that's the intention here. Why not use UTF-8? Gary On Sun, Dec 29, 2019 at 8:28 AM Gary Gregory <garydgreg...@gmail.com> wrote: > On Sun, Dec 29, 2019 at 4:20 AM Alex Herbert <alex.d.herb...@gmail.com> > wrote: > >> On Sun, 29 Dec 2019, 01:14 Gary Gregory, <garydgreg...@gmail.com> wrote: >> >> > It looks like public methods have been removed >> > from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, >> These >> > need to go back in to maintain binary compatibility. Then we can have a >> > release candidate. >> > >> >> To fix the broken hash implementation a new parent class with the correct >> implementation was introduced and some methods bumped up to that. So the >> methods still exist but they are in the parent class. When I ran clirr >> during the development it did not complain. Is there a report stating that >> binary compatibility is broken? Maybe JApiCmp has a different opinion. >> >> Doing it this way allows the broken class to be deprecated. The other way >> to have the new correct class as the child means that the broken class >> cannot be deprecated as it has a child. Making the broken method >> deprecated >> would then have a child overriding a deprecated method. >> > > You're correct, I misread the JApiCmp report. Sorry about that. > > Gary > > >> >> Alex >> >> >> > Gary >> > >> > On Fri, Dec 27, 2019 at 7:02 PM Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > >> > > On Fri, Dec 27, 2019 at 3:18 PM Alex Herbert < >> alex.d.herb...@gmail.com> >> > > wrote: >> > > >> > >> >> > >> >> > >> > On 27 Dec 2019, at 16:35, Gary Gregory <garydgreg...@gmail.com> >> > wrote: >> > >> > >> > >> > Great, TY. Feel free to add more tests if need be. Edge cases and >> so >> > on. >> > >> > >> > >> > Gary >> > >> >> > >> If you look at the Jacoco report for MurmurHash3 the only line >> missing >> > >> execution is the throwing of an AssertionError in a default block of >> a >> > >> switch statement for a line that should not be possible to reach >> (line >> > >> 1057). >> > >> >> > >> So it is missing coverage of unreachable code. >> > >> >> > >> This is part of the original code that I did not update. I can >> rewrite >> > it >> > >> to drop the unreachable code but as it stands it is self documenting. >> > >> >> > >> My preference would be to drop the unreachable code. It is not there >> > >> because it needs to be, for example a catch block to handle a >> declared >> > >> exception that you never expect. It seems to be to add a default >> block >> > for >> > >> the switch statement. >> > >> >> > > >> > > I'm OK to drop the code, or replace the AssewrtionError with an >> > > IllegalStateException? If any kind of code remains, the exception >> message >> > > and/or comment should state "this should not happen" but I can >> imagine it >> > > could if someone put this through some fuzzer. >> > > >> > > Gary >> > > >> > > >> > >> WDYT? >> > >> >> > >> Alex >> > >> >> > >> >> > >> > >> > >> > On Fri, Dec 27, 2019 at 10:54 AM Alex Herbert < >> > alex.d.herb...@gmail.com >> > >> > >> > >> > wrote: >> > >> > >> > >> >> I'll have a look at this since I rewrote the code and all the >> tests >> > to >> > >> fix >> > >> >> the hash implementation. >> > >> >> >> > >> >> Alex >> > >> >> >> > >> >> On Fri, 27 Dec 2019, 15:18 Gary Gregory, <garydgreg...@gmail.com> >> > >> wrote: >> > >> >> >> > >> >>> Hi Claude, >> > >> >>> >> > >> >>> Is there any way we could get 100% code coverage >> > >> >>> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left >> > >> >> untested. >> > >> >>> >> > >> >>> To see the code coverage, look at the JaCoCo report in >> > >> >>> target\site\index.html under 'Project Reports' after running 'mvn >> > >> clean >> > >> >>> package site -P jacoco -P japicmp' >> > >> >>> >> > >> >>> Gary >> > >> >>> >> > >> >>> On Thu, Dec 26, 2019 at 5:03 PM Claude Warren <cla...@xenei.com> >> > >> wrote: >> > >> >>> >> > >> >>>> For the contributions and issues I was involved in, the javadoc >> > >> appear >> > >> >> to >> > >> >>>> be correct. >> > >> >>>> >> > >> >>>> Claude >> > >> >>>> >> > >> >>>> On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory < >> > garydgreg...@gmail.com >> > >> > >> > >> >>>> wrote: >> > >> >>>> >> > >> >>>>> It looks like we will need a new version of Commons Codec out >> > before >> > >> >> we >> > >> >>>> can >> > >> >>>>> use new code there from Commons Collections. So now's the time >> to >> > >> >>> polish, >> > >> >>>>> PR, and so on. >> > >> >>>>> >> > >> >>>>> If you've contributed code to Codec, please make sure the >> Javadoc >> > >> are >> > >> >>>>> helpful and the site up to date. >> > >> >>>>> >> > >> >>>>> Thank you! >> > >> >>>>> Gary >> > >> >>>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> -- >> > >> >>>> I like: Like Like - The likeliest place on the web >> > >> >>>> <http://like-like.xenei.com> >> > >> >>>> LinkedIn: http://www.linkedin.com/in/claudewarren >> > >> >>>> >> > >> >>> >> > >> >> >> > >> >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> > >> >> > >> >
