Another fix would be making the hashcode variable transient.
I prefer the suggested approach cause if anyone is using the hashcode function he can expect the value to remain the same

Well if you open a PR to fix a bug it woild be really nice if you could explain in depth why the issue occurred in the first place ;)

i think the real issue here is that it's relying on the hashCode being stable, which is not a safe assumption

Well if you open a PR to fix a bug it woild be really nice if you could explain in depth why the issue occurred in the first place ;)

All the details are in the linked issue.

i think the real issue here is that it's relying on the hashCode being stable, which is not a safe assumption

I mean we could just put a transient on the cached variable, that would solve the problem without assuming that they maintain the same hashcode

The linked issue does not describe where the problem originates from. It only generically describes an issue with serialising/deserializing packet containers...

The linked issue does not describe where the problem originates from. It only generically describes an issue with serialising/deserializing packet containers...

It seems that when looking up the the clazz of a PacketType it fails to find it that's because the hashcode of the deserialized PacketType doesn't match with the hashCode of the packetType inside the registry.

This is expected behavior bc the specs doesn't guarantee the same hashcode for different executions

To add more context, you serialize a packetContainer and when trying to deserialize it protocol lib does what I've describeded above and it fails.

I think using hashCode() is unreliable when working with the Minecraft protocol in general. Most NMS packets do not properly implement equals() and hashCode()

The linked issue does not describe where the problem originates from. It only generically describes an issue with serialising/deserializing packet containers...

It seems that when looking up the the clazz of a PacketType it fails to find it that's because the hashcode of the deserialized PacketType doesn't match with the hashCode of the packetType inside the registry.

This is expected behavior bc the specs doesn't guarantee the same hashcode for different executions

To add more context, you serialize a packetContainer and when trying to deserialize it protocol lib does what I've describeded above and it fails.

right, so in my mind a proper fix addresses the fact that serialization relies on hashCode instead of something stable

right, so in my mind a proper fix addresses the fact that serialization relies on hashCode instead of something stable

okay, I'm gonna try to add the modifier transient to the hashcode cache variable, that should fix the problem without
relaying on a specific custom behavior

--- edit
tested it and the problem is fixed that way