Finish the match key rename in the 51Did payload constants - #120
Merged
Conversation
The earlier rename of the stable, comparable part of a 51Did to "match key" was only half done. Two payload constants still carried the old hash name even though their own documentation already called the field a match key, so the code read one way and the names read another. MATCH_KEY_OFFSET and MATCH_KEY_LENGTH are now the real constants and keep their values of 5 and 32. HEADER_LENGTH and PAYLOAD_LENGTH keep their own names and are worked out from the new constants. HASH_OFFSET and HASH_LENGTH stay as deprecated aliases of the same two values, worded the same way as the getHash alias already in the file, so code written against the earlier names keeps compiling. All 23 uses of the old names move to the new ones, across the 51Did package, its tests and the 51Did developer example, and the package README now describes the naming. A test asserts the two aliases still read the same values as the constants they point at. Nothing to do with SHA-256 hashing itself, or with the unrelated Device Detection Hash classes, is renamed.
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
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 problem
The stable, comparable part of a 51Did is called the match key. That
rename reached the accessor, where
getMatchKey()is the real method andgetHash()is kept as a deprecated alias, but it never reached the payloadconstants in
FodId.java.Two constants still carried the old hash name even though their own
documentation already described the field as the match key, so the comment
and the name disagreed on the same line.
Anyone reading the class had to work out for themselves that the two names
meant the same thing as
getMatchKey().What changed
MATCH_KEY_OFFSETandMATCH_KEY_LENGTHare now the real constants. Theykeep the values they had, 5 and 32, and they keep the documentation they
had, which already used the right words.
HEADER_LENGTHandPAYLOAD_LENGTHkeep their own names, which were neverwrong, and are now worked out from the new constants.
Every use of the old names moves to the new ones, which is 23 references
across six files.
pipeline.did/.../FodId.javapipeline.did/.../DidClient.javapipeline.did/.../FodIdTestFactory.javapipeline.did/.../FodIdTests.javapipeline.developer-examples/.../fodid/Main.javapipeline.developer-examples/.../fodid/ExampleTests.javaThe 51Did package README
gains a short paragraph next to the existing
getHash()note, so theconstant naming is described in the same place as the accessor naming.
Nothing to do with SHA-256 hashing itself is renamed, and the unrelated
Device Detection Hash classes are untouched.
Why the old names are kept
HASH_OFFSETandHASH_LENGTHstay as deprecated aliases of the newconstants, so code already written against the earlier names keeps
compiling and reads the same values.
The wording follows the
getHash()deprecation already in the same file,so a reader meets one explanation of the rename rather than two, and the
two aliases will be removed together in a future release.
How it was verified
A new test asserts the aliases still read the same values as the constants
they point at, because a deprecated alias nothing exercises is an alias
nobody notices breaking.
Built and tested with Apache Maven 3.9.16 on Java 21.0.11.
mvn -B -pl pipeline.did testThe two skipped tests are
DidClientLiveTests, which are skipped by designbecause they call the live cloud service and no resource key was supplied.
mvn -B -pl pipeline.did,pipeline.developer-examples,pipeline.developer-examples/pipeline.developer-examples.fodid testThe Java 8 signature check that this module runs over its compiled classes
also passed, so the change stays inside the API floor the module holds
itself to.
A repository-wide search for the two old names now returns six lines only,
being the two deprecated alias declarations in
FodId.java, the twoassertions and the comment in the new test, and the sentence in the README
that describes the aliases. No working code reads the old names any more.
Outstanding
Nothing in this repository. The same pair of constants may carry the old
name in the other language ports of the 51Did reader, which is worth a
check before the aliases are removed.
The pull request is left open and is not merged.
Produced with AI assistance under James Rosewell's direction and needs human review.