Update zero-allocation-hashing and xx hash method name

[shivamgupta1]

Summary

The zero-allocation-hashing library versions > 0.7 are missing the method LongHashFunction.xx_r39 required by pegasus, thus causing failures. However, it appears that the newer versions are being increasingly used by OSS libraries and thus with LI too.

It looks like they just renamed xx_r39 (xxHash algo release 39) to xx to stop tying it to a particular release: OpenHFT/Zero-Allocation-Hashing@658079a

Thus, it should be safe for us to move over to xx.

[zackthehuman]

I think this is going to be a breaking change, or at least require a lot of spot fixing when it re-enters the internal LinkedIn ecosystem. If you check internal code search, we use LongHashFunction.xx_r39 all over the place. I think this was a mistake on behalf of the library owner to remove LongHashFunction.xx_r39 from the public API on a minor release. Since this is a minor version bump for pegasus, it's going to result in broken builds for any code base that pulls in pegasus with this change. We are not currently planning on releasing the next major version of pegasus, so a change like this is worrisome. Can you help em understand what the rollout plan is? (We can discuss internally). cc @mchen07

Side note: I don't think we should link to our internal systems (JIRA/Slack/etc.) from OSS PRs.

[bohhyang]

can we roll it out with a minor version bump, like 29.49.0?

[zackthehuman]

can we roll it out with a minor version bump, like 29.49.0?

Not without introducing runtime breaking changes and a lot of toil to clean up. Instead, we should try to migrate our internal usage of LongHashFunction.xx_r39 to LongHashFunction.xx. We are trying to upstream as patch to make that possible: OpenHFT/Zero-Allocation-Hashing#84. If we can leverage that patch then we will have a smooth path forward that doesn't involve breaking pegasus users' runtimes.

[bohhyang]

this can use the custom fork now, right?

[zackthehuman]

Not yet; the custom fork is only released internally to LinkedIn. We need to update internal users to use our fork, and then change their code to use xx() instead of xx_r39(). After that, we are free to use net.openhft:zero-allocation-hashing:0.16 in Pegasus. We won't need to fork anymore at that point.

[bohhyang]

got it. Thanks!