Why?

Java's native serialisation is inherently unsafe and shouldn't be used in untrusted environments, which includes any Minecraft client and server, for as there's no guard to prevent anyone from defining something invalid, crashing the network layer as a result, or presenting more severe exploits.

Problems this causes

• Effectively a security hazard; Java's serialisation shouldn't be used in any meaningful capacity in environments that cannot be fully trusted by either client or server, as a given server or client can try to misuse any ill-defined code that does things it shouldn't to break the other end.
• Creates protocol incompatibility for a given client & server.
  • Serialisation doesn't have a stable ABI, and can be changed by simply using it in a development environment trying to connect to a production environment, or by version updates that unexpectedly changes things that would've otherwise been entirely compatible. Different versions of Java has historically been known to also cause issues with this.

Replacements

Use a container such as NBT or manually encode into the packet.

NBT would provide an entirely stable ABI that is both forward and backwards compatible, assuming the code for it remains in place.

Encoding into the packet will let you define the compatibility to a finer degree, while still preventing exploits.

Both solutions, as long as you're not trusting with arbitrary execution of methods (raw reflection lookups), will provide much stronger protocol compatibility across JVMs and environments, while also hardening the mod from any attacks that may take advantage of network-exposed Object streams.

Offending lines