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. 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 > >> > >> >
