New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AbstractHttp2StreamFrame
and DefaultHttp2PingFrame
hashCode
seems incorrect
#13659
Comments
@Marcono1234 sounds like a bug... Can you please open A PR ? |
@normanmaurer, will this require me to sign the Contributor License Agreement? In that case, sorry I won't create a pull request. |
@Marcono1234 yes it will require signing a CLA |
Ok, thanks for the confirmation. As mentioned above, in that case I will not submit a PR, sorry. |
Motivation: Our implementations of hashCode() and equals(...) were not correct for some frames. Modifications: Correctly implement both methods Result: Fixes #13659
Expected behavior
The
hashCode
methods should return the same result for objects which are considered equal, according toequals
.Actual behavior
The
hashCode
methods return different results.The reason is that they call
super.hashCode
, which is actuallyObject.hashCode
, and therefore differs between instances.For
DefaultHttp2PingFrame
a possible solution (which would also include thecontent
field) could look like this:Steps to reproduce
see reproducer code below
Minimal yet complete reproducer code (or URL to code)
AbstractHttp2StreamFrame
:DefaultHttp2PingFrame
:Netty version
4.1.100.Final
JVM version (e.g.
java -version
)Java 17
OS version (e.g.
uname -a
)Windows 10
The text was updated successfully, but these errors were encountered: