Kryo Changelog

What's new in Kryo 5.6.0

Jan 8, 2024

Avoid creating GenericsHierarchy when generics optimization is disabled
BigDecimal serializer memory and throughput optimizations (thanks @gdela)
Avoid allocation in BigDecimal serializer with new methods for bytes in Input/Output (thanks @gdela)

New in Kryo 5.5.0 (Apr 20, 2023)

New in Kryo 5.4.0 (Dec 30, 2022)

New in Kryo 5.3.0 (Feb 11, 2022)

New in Kryo 5.2.1 (Dec 11, 2021)

New in Kryo 5.2.0 (Jul 31, 2021)

New in Kryo 5.1.1 (May 3, 2021)

New in Kryo 5.1.0 (Apr 8, 2021)

New in Kryo 5.0.4 (Mar 13, 2021)

New in Kryo 5.0.3 (Dec 15, 2020)

New in Kryo 5.0.2 (Dec 4, 2020)

New in Kryo 5.0.1 (Nov 22, 2020)

New in Kryo 5.0.0 RC6 (May 17, 2020)

New in Kryo 5.0.0 RC4 (Apr 15, 2019)

New in Kryo 5.0.0 RC3 (Apr 9, 2019)

New in Kryo 5.0.0 RC2 (Feb 6, 2019)

New in Kryo 5.0.0 RC1 (Jun 19, 2018)

This is the first release candidate of the new major version of Kryo, which fixes many issues and makes many long awaited improvements.
Major changes:
Generics has been redone to support all scenarios. GenericsUtil thoroughly discovers the generic types that are known at compile time (tests), which avoids as much work as possible during serialization. The generic types known only at serialization time are tracked by Kryo's instance of Generics, which maintains a stack of GenericType instances (lots of nice javadocs in those classes).
How does using the new generics API look? For a simple example with just one type parameter, see CollectionSerializer. To get the class, call kryo.getGenerics().nextGenericClass() then after reading the child objects call kryo.getGenerics().popGenericType(). Simple!
nextGenericClass() is a shortcut for the common case of a class with a single type parameter. When there are multiple type parameters, like Map, use nextGenericTypes() instead, then call resolve() to get each class. Also, the last parameter is made current automatically (meaning it is pushed by Generics#nextGenericTypes()), so the other parameter(s) have to be pushed and popped manually. Somewhat less simple!
It's a little tricky, but these two patterns are all serializers need to worry about. It provides full support for nested generic types, eg HashMap<ArrayList<Integer>, ArrayList<String>>, which wasn't possible before.
Feedback on all this is welcome, but the core of it is relatively complex and may induce a headache (it certainly did when writing it!). The important bits are 1) to handle all generics scenarios, and 2) to minimize work at serialization time. Digging through just the calls for generics made from serializers, you'll find minimal work is done and without allocations. Given this, generics are always enabled.
Serializer method signatures have changed for issue #146 in this commit. All Serializer classes need to be changed from Class<T> to Class<? extends T>.
Various serialization improvements. Eg, TaggedFieldSerializer now has acceptsNull=true, which saves 1 byte for all non-null objects.
Unsafe had permeated the API. IMO it should be sandboxed as much as possible. I began refactoring by removing Unsafe support completely, made everything nice, then put back the input/output streams. I haven't yet looked into what serializers would need to make use of all of the Unsafe features. With Java 9 dropping Unsafe, maybe it is not worth the considerable effort to support it. FWIW, I personally don't use Unsafe but I know others do. I assume some even choosing Kryo specifically for Unsafe. I don't know how those people feel about Java 9.
I have not looked at Java 9 at all yet. I don't know if it provides APIs that Kryo can use to be more efficient.
FieldSerializer had gotten messy internally. It did a lot more work than necessary to build the cached fields. It did things with generics that were suspect and did expensive computations that were not even used. It had a lot of Unsafe logic.
Various API improvements. The Kryo class must not become a junk drawer for serializer settings. The SerializerFactory classes can be used, eg FieldSerializerFactory, which can create new, configured serializers (example). Having Input/Output varint and varlong be a hint was odd. If this ends up being needed again, maybe depending on what happens with Unsafe, it could be done in Input/Output subclasses without affecting the base class API. Javadocs are much improved.
Logging is improved. Some useless junk was logged, some important junk was not logged, and the formatting of log messages was not consistent.
Deserialization still temporarily modifies the input buffer. While in many cases this is fine, it can be quite an unexpected gotcha in some cases. I'd like to remedy this but string writing is important and any changes here need extensive benchmarks.

New in Kryo 4.0.2 (Mar 21, 2018)

New in Kryo 4.0.1 (Mar 19, 2018)

New in Kryo 2.24 (May 5, 2014)