Serializable Java Lambdas
Serializable Java Lambdas
Here's an article that should help with a specific error that might occur when trying to serialize a lambda with Kryo.
Join the DZone community and get the full member experience.Join For Free
Recently I was presented with the following error when serializing a lambda with Kryo:
If you do not recognize the
(Runnable & Serializable) syntax, don’t worry, it is merely stating that the lambda must implement two types. This is called Type Intersection. Personally, I have never needed to use this myself, so have never really thought about it.
Serializable is a bit of a unique interface in this regards, as there is nothing you actually need to implement.
Without making this cast, the lambda will be considered unserializable, which does not make Kryo happy.
You may also enjoy: How and Why to Serialize Lambdas
As someone who doesn’t look at bytecode very often, I find it amazing how big the difference is when adding and extra casting of
& Serializable. The examples below demonstrate this. For clarity, I used the following command to generate bytecode from the code snippets:
Before doing any casting:
The generated bytecode is:
The bytecode becomes:
Now, I don’t really know how to read bytecode, but even I can see that there is a lot more going on in the version with the
& Serializable cast.
If you can explain what is going on there, then be my guest and give me a shout.
One thing I can read from the bytecode above, is the references to
SerializedLambda which were not there before. This class is used by compilers and libraries to ensure that lambdas deserialize correctly. Making the intersection cast of
Function<String, String> & Serializable changes the underlying type of the lambda, allowing a library like Kryo to properly understand how to deserialize lambdas given to it.
Adding this extra casting of
& Serializable is one possible solution to allow Kryo to deserialize lambdas. An alternative route involves creating a new interface that extends both the underlying
Function type that you need, along with
Serializable. This is useful when putting together a library or API for others to consume. Allowing them to focus purely on implementing their code, rather than worrying about providing the correct casting to satisfy the serialization of their lambdas.
You could use an interface like the one below:
This can then be used to replace the casting in the previous example:
I have added the bytecode generated by this change below:
Most of it is the same, with some new references to the
SerializableLambda interface and the removal of the original intersection cast.
As mentioned before, this solution is ideal for library and API authors as it allows developers to write code as usual without having to worry about casting (for example, if the library uses Kryo under the hood). Furthermore, since the interface extends
Function which is a
@FunctionalInterface, developers can nicely write lambdas/functions and don’t even have to mention the interface if passing it directly into another function or constructor. I personally went down this route when designing a new API for Corda. I wanted to provide the most accessible API for developers to use, while still providing an API that works (I can’t let Kryo blow up…).
In conclusion, in this post which lacks a lot of information and is littered with extended snippets of bytecode, you need to take away two things. You can make a Java lambda/function serializable through type intersection, and you can ensure that your own APIs are clean by creating a new interface that extends both your desired function type and
Serializable. These are both routes that should be considered when using a serialisation library like Kryo.
If you enjoyed this post or found it helpful (or both) then please feel free to follow me on Twitter at @LankyDanDev and remember to share with anyone else who might find this useful!
Introduction to Java Bytecode
Published at DZone with permission of Dan Newton , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.