Kryo 5.6.2: binary serialization and cloning for Java object graphs

What Kryo is for, and who ends up using it

Kryo is a binary serialization framework for Java object graphs, and it also performs deep and shallow copying. The README states the project goals plainly: high speed, low size, and an easy to use API, and it says the library is useful any time objects need to be persisted, whether to a file, a database, or over the network. The README also notes that the copying path is direct object to object, not object to bytes to object, which is a different operation from serialization and is often the reason a team picks it up.

The audience is narrower than "all Java projects". You need control of the class definitions on both sides of the wire, or at least a stable agreement about them, because Kryo writes class identity into the stream through its class resolution machinery. Teams that already use Java serialization and want smaller payloads, or that hand-roll DataOutputStream code and want to stop, are the natural fits. The README points questions at the Kryo mailing list and asks that the issue tracker be limited to bugs and enhancements, which tells you the project expects users to read the documentation before filing.

How the serializer, class resolver and buffer layers fit together

The architecture has three visible layers. At the bottom is IO: Output and Input wrap byte buffers, with variants for ByteBuffers and for unsafe buffers, and the documentation describes variable length encoding and chunked encoding on top of them. In the middle is the serializer framework, where each class maps to a Serializer implementation. FieldSerializer is the default workhorse and reflects over fields; VersionFieldSerializer, TaggedFieldSerializer, CompatibleFieldSerializer and BeanSerializer are alternatives with different rules about how a class may change later. At the top sits Kryo itself, which owns a ClassResolver and a reference resolver.

Registration is the part that shapes your format. The ClassResolver turns a class into the integer written into the stream, and the README documents both explicit registration and optional registration through a ClassResolver setting. Explicit registration assigns small integers and keeps payloads tight; optional registration lets unregistered classes through, which the documentation presents as a convenience with a cost. References are the other shaping decision: Kryo tracks object identity so that a graph with shared or cyclic references round trips correctly, and the README documents ReferenceResolver and reference limits for bounding that tracking. Reset returns a Kryo instance to a reusable state, which is the documented basis for pooling.

Installing Kryo with Maven and running a first round trip

Kryo publishes two kinds of artifacts, and the README is explicit about which one you want. Applications should depend on the default jar with its usual library dependencies. Libraries that will be published should depend on the dependency-free, versioned jar so that different libraries can use different major versions of Kryo side by side. For an application, the README gives this entry for pom.xml:

<dependency>
   <groupId>com.esotericsoftware</groupId>
   <artifactId>kryo</artifactId>
   <version>5.6.2</version>
</dependency>

For a library you intend to publish, the coordinates change to groupId com.esotericsoftware.kryo and artifactId kryo5, with the same version. Snapshots live in the Sonatype snapshots repository at https://oss.sonatype.org/content/repositories/snapshots. The README also points at the releases page and Maven Central, and describes building from source as an option; the repository root contains main/, main-versioned/, pom.xml and test directories, which matches that layout.

Once the dependency resolves, the smallest useful program registers a class and round trips an instance. The README's Quickstart section is the reference for this shape of code: create a Kryo, register the class, write the object to an Output, then read it back from an Input. The important thing to observe is that the object you get back is a new instance, not the one you wrote, and that shared references inside the graph survive when reference tracking is enabled. If you skip registration while optional registration is off, the write fails with a KryoException rather than silently producing a larger payload.

The constraints that decide whether Kryo is the wrong tool

The first constraint is thread safety. The README has a Thread safety section and a Pooling subsection, and the documented model is that a Kryo instance is not safe to share across threads without care. Pooling is the suggested answer, which means every call site has to borrow, use, and return an instance, and the reset step has to actually run. Code that stashes a Kryo in a static field and calls it from a request thread pool is a bug waiting for load.

The second constraint is that the format is not self-describing in the way a schema-based encoding is. Registration order and serializer choice are part of the contract, so two services must agree on them. The README addresses this under Compatibility and Replacing a class, and offers VersionFieldSerializer, TaggedFieldSerializer and CompatibleFieldSerializer precisely because plain FieldSerializer does not tolerate arbitrary class changes. Choosing FieldSerializer for a long-lived persisted format and later renaming a field is the classic way to lose data.

The third constraint is deserialized size. The README includes a section titled Limiting deserialized size, which exists because an attacker or a corrupt stream can declare a length that your process then tries to allocate. If you accept Kryo bytes from an untrusted source, that limit is not optional. The README does not document a rollback procedure for a bad deployment of a changed serializer, so plan the compatibility story before you write the first byte.

Kryo against Java serialization and schema-based encodings

The closest comparison is Java's built-in serialization. Both write a Java object graph to bytes and both rely on the class definitions being present at read time. The difference is in the mechanism: Java serialization carries class descriptors and field names into the stream, while Kryo's ClassResolver substitutes small integers for classes, which is why the README describes the output as low size and why registration changes the payload. Java serialization also has a documented, if awkward, evolution story through serialVersionUID; Kryo pushes that decision onto the serializer you pick, and the README documents four field serializers with different compatibility rules instead of one default.

Schema-based encodings such as Protocol Buffers or Avro take the opposite approach: you write a schema, generate code, and any language can read the result because the schema travels separately. Kryo has no schema file and no cross-language reader in this repository; the README's interoperability section and its links to Scala, Clojure and Objective-C are about usage from those ecosystems, not about a portable wire format. If a non-JVM consumer has to read your data, or if two teams need to negotiate field changes without shipping code together, a schema-based encoding is the better fit and Kryo's speed advantage does not compensate for the missing contract.

Maintenance, upgrading and the licence you are accepting

The repository is not archived, and the last push was on 2026-09-21, so the project is being touched. Release cadence is a separate signal: the most recent releases listed are 5.6.2 on 2024-10-10, 5.6.1 on 2024-10-07 and 5.6.0 on 2024-01-08. The 5.6.2 release note says it recompiles 5.6.1 to be compatible with Java 8 again, which is a useful reminder that the build target can shift between patch releases and that a patch bump is worth reading before you take it.

Upgrade cost is dominated by the serialization contract, not by the library. The README has a section on Kryo versioning and upgrading, and the 4.x documentation lives on the wiki separately from this 5.x README, so a jump across a major version means reading two documents. Within 5.x, the versioned artifact exists so that libraries can pin different major versions, but your own persisted data still has to be readable by whatever serializer configuration you deploy next.

Kryo is licensed under BSD-3-Clause. That is a permissive licence, and the practical implication for adopters is that you can ship it inside a closed product provided you keep the copyright notice and licence text with the distribution. This is not legal advice; check the LICENSE.md file in the repository and your own counsel for the obligations that apply to your distribution model.

Editorial conclusion

Kryo fits applications that control both ends of the data and want compact binary output plus direct object copying: caches, inter-service messages, RPC payloads, and deep clones of mutable graphs. It is the wrong choice when a foreign process must read the bytes without a Kryo dependency, or when you need a schema negotiated across teams, because the format is a product of your registration and serializer choices. Before adopting it, verify three things in your own build: that you use the plain com.esotericsoftware:kryo artifact rather than the versioned kryo5 artifact meant for libraries, that every class you serialize is registered or optional registration is enabled deliberately, and that your thread-safety plan matches the documented requirement that Kryo instances are not thread safe.

Frequently asked questions

Official sources

1. EsotericSoftware/kryo on GitHub
2. Issues
3. License: BSD-3-Clause
4. README
5. Releases