Open zackthehuman opened 8 months ago
@peter-lawrey Any chance you're be open to merging this change?
Trying @peter-lawrey-admin to see if this is an acceptable request.
@zackthehuman sorry for the long delay in getting back to you. Thanks very much for putting this PR together.
Is this PR still blocking you? If so please can you sign the contributor agreement here: https://chronicle.software/contributor-agreement/
@tgd Thanks for the reply. Yes, landing this change will still unblock me. I've signed the CLA now.
Add alias to LongHashFunction.xx() called LongHashFunction.xx_r39() to allow consumers to migrate code from xx_r39() to xx() without breaking at runtime.
The LongHashFunction.xx_r39() method delegates to LongHashFunction.xx() so it is identical in behavior. It's marked as deprecated.
Context
Some large companies make use of
Zero-Allocation-Hashing
because it is so useful. In https://github.com/OpenHFT/Zero-Allocation-Hashing/commit/658079a50903c32c54f2ab5c86243244b3ac60ed theLongHashFunction.xx_r39()
method was renamed to the more generalLongHashFunction.xx()
. Since this method is public, this was a breaking change. Since the cutover fromLongHashFunction.xx_r39()
toLongHashFunction.xx()
was immediate, any consumer has to ensure that their code no longer usesLongHashFunction.xx_r39()
as well as any of their (potentially compiled) dependencies. If a dependency was compiled against an older version ofZero-Allocation-Hashing
whereLongHashFunction.xx_r39()
still exists, then it will blow up at runtime since the method can no longer be found on the class.At LinkedIn, we use
Zero-Allocation-Hashing
both in our internal and open-source libraries. We want to update to the latest version, but cannot easily do it without a way to cut over fromLongHashFunction.xx_r39()
toLongHashFunction.xx()
.Please consider merging this patch for compatibility's sake. It will help software developers keep their dependencies up to date!