kutsibalci commented on PR #23098:
URL: https://github.com/apache/kafka/pull/23098#issuecomment-5422918828
Twenty days, and the gate is still closed — `CI` and `Pull Request Reviewed`
are both still sitting
at `action_required` against `65ab88172`, so no build has ever run on this
PR. Nothing has changed
since the ping above; I am only re-raising it because the PR cannot move
without someone pressing
the button, and I would rather it be visible than quietly rot.
I re-read `TokenInformation.java` on `trunk` this morning to be sure the
finding had not been fixed
underneath me. It has not:
- `equals` (line 140) compares **six** fields — `issueTimestamp`,
`maxTimestamp`, `owner`,
`tokenRequester`, `renewers`, `tokenId`.
- `hashCode` (line 150) hashes **seven** — the same six plus
`expiryTimestamp`.
So two `TokenInformation` objects that differ only in `expiryTimestamp` are
`equals` but hash
differently, which is the `Object.hashCode` contract violation.
`expiryTimestamp` is also the one
field with a setter, so it is exactly the field that must not be in a hash
key. Removing it from
`hashCode` keeps `equals`'s existing intent; adding it to `equals` would
change behaviour for
callers, which is why the patch goes the way it does.
@ashwinpankaj — you were the last to commit to this file. @ijuma — you fixed
this same defect class
in `Struct.equals` a while back, so you may be the fastest person to
sanity-check whether this one
is worth the CI minutes at all. If the answer is "not worth it", I would
genuinely rather hear that
and close it than leave it open.
Happy to rebase onto current `trunk` first if that makes the run easier.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
