Rename FodId hash to match key to match the Model Terms vocabulary - #119
Merged
Conversation
The stable, comparable part of a 51Did, the payload bytes after the Flags and License Id, is called the match key in the Model Terms for Marketing and in the patent, so the reader now uses the same word. getHash() stays as a deprecated alias forwarding to getMatchKey() so that existing callers keep compiling and get the same bytes. The private field, constructor parameter and parse walk locals move to match key naming. HASH_OFFSET and HASH_LENGTH keep their names because the SHA-256 wording behind them stays true, and their javadoc now describes the match key field. The class javadoc, package-info, pom description, FodIdParseStatus javadoc and README use the new word.
Every test that meant the match key now calls getMatchKey(), and the constant, factory method and test names that meant it are renamed. One new test, getHash_DeprecatedAlias_ReturnsMatchKey, is the only caller of the deprecated getHash() and asserts it returns the same bytes as getMatchKey(). The root pom compiles with -Werror, so that test carries a deprecation suppression and any other use of the old name would fail the build.
The offline example reads the match key with getMatchKey(), prints it under that name, and its README, comments and self check describe the match key as the stable part while the envelope changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The stable, comparable part of a 51Did (the payload bytes after the Flags and License Id) is now called the match key, which is the word the Model Terms for Marketing and the patent use for it. The Java reader previously exposed it as
FodId.getHash(). This change mirrors the .NET rename (51Degrees/pipeline-dotnet#348) and the Rust rename (51Degrees/rust#19), and sits on top of the parse hardening change (#118) merged today.Change
FodId.getHash()toFodId.getMatchKey(), and move the private field, the constructor parameter and the locals in the parse walk that carry the same bytes to match key naming.getHash()as a@Deprecatedalias forwarding togetMatchKey(), so existing callers keep compiling (with a deprecation warning) and get the same bytes. Its javadoc says@deprecated renamed to getMatchKey(), and the alias will be removed in a future release.HASH_OFFSETandHASH_LENGTHkeep their names because the SHA-256 wording behind them stays true. Their javadoc now describes the match key field.FodIdclass javadoc,package-info.java, the pom description, thepipeline.didREADME, theFodIdParseStatusjavadoc and the 51Did developer example (pipeline.developer-examples.fodid) to the match key vocabulary. The README also says thatgetHash()remains as a deprecated alias.getMatchKey(), rename the test constant and methods that mean the match key (CANONICAL_MATCH_KEY,canonicalMatchKey(),matchKey_IsDefensiveCopy,compareTwo51Dids_SamePayload_SameMatchKeyDifferentEnvelopes,constructor_RandomPayloadLargerThanSpec_UsesFirst16MatchKeyBytes), and add one test,getHash_DeprecatedAlias_ReturnsMatchKey, which is the only place the deprecated alias is called and which asserts it returns the same bytes asgetMatchKey().Compiler settings
The root pom compiles every module with
-Xlint:all -Werror, so any remaining internal call togetHash()would fail the build. No production code calls the alias, and the one test that does carries@SuppressWarnings("deprecation"). Removing that annotation and recompiling the test sources fails with "warnings found and -Werror specified", which confirms the setting is live and that no other caller of the old name remains.Tests
On JDK 21 with Maven 3.9.16.
pipeline.didran 126 tests with 0 failures and 2 skipped (the two live cloud tests, skipped on main as well). The 126 is main's 125 plus the new alias test.pipeline.developer-examples.fodidran 9 tests with 0 failures.mvn install -DskipTeststhenmvn surefire:testat the root, completed with BUILD SUCCESS for both steps and no test failures across the 25 modules (the skipped tests are the live cloud ones, skipped on main as well).Part of the cross-repository match key rename, alongside the .NET reader (51Degrees/pipeline-dotnet#348) and the Rust reader (51Degrees/rust#19), with the documentation, Website and cloud internals in separate PRs.
Produced with AI assistance under James Rosewell's direction and needs human review.