- Fast Serialization reimplements Java Serialization with focus on speed, size and compatibility. This allows the use of FST with minimal code change.
- ByProducts are OffHeap Maps, Persistent Maps, Struct emulation
- Faster serialization and smaller object size.
drop-in replacement. Does not require special getters/setters/Constructors/Interfaces to serialize a class. Extends Outputstream, implements
ObjectInput/ObjectOutput. Few code changes required.
- Full support of JDK-serialization features such as Externalizable writeObject/readObject/readReplace/validation/putField/getField, hooks etc.. If an object is serializable with JDK, it should be serializable with FST without any further work.
- preserves links inside the serialized object graph same as JDK default serialization
- custom optimization using annotations, custom serializers
- supports versioning (2.x only)
- conditional decoding (skip decoding parts of an object/stream in case)
Supports java 1.7+ (fst 1.62: JDK 1.6)
- fst 1.x is jdk 1.6 compatible (no use of 1.7 features). I backport 2.x fixes from time to time or upon request
- FST-structs does require 1.7 API
download non-maven build at the releases section: https://github.com/RuedigerMoeller/fast-serialization/releases/
Note: fixes+updates are delivered with some delay to maven central, check downloads first for newest versioncurrent:
<dependency> <groupId>de.ruedigermoeller</groupId> <artifactId>fst</artifactId> <version>2.19</version> </dependency>
<dependency> <groupId>de.ruedigermoeller</groupId> <artifactId>fst</artifactId> <version>1.63</version> </dependency>
FST Serialization should be pretty stable and JDK-serialization compatible today. It is used in a large distributed high performance application. Additionally a lot of remaining corner cases (mostly JDK-serialization-compatibility-issues) have been fixed when replacing JDK-serialization in a prime-faces webflow webapp (lot's of rarely used constructs in there).
Also see this blog post.
- specialized on java-to-java, no inter language operability.
- reads/writes to a temporary buffer in memory to speed up things. This might impose a problem when reading/writing huge objects > 100MB
- emulating JDK built in
Externalizableis somewhat tricky. FST needs to speculate on the maximum size of a single externalizable instance. Default setting is 8kb. In case you use
Externalizableand write large binary data from one single
Externalizableinstance without return control to the serializer, you have to increase both
FSTObjectInputclass. You might also consider to just replace
Serializable. In fact FST frequently does
Serializablefaster than built in JDK
- direct reading from a blocking stream (e.g. socketinputstream): see answer and example in this issue
I measure different typical use cases (both classes with lots of native data and structural complex object graphs). The benchmarks assures, that only serialization speed is measured. Creation of
ByteArrayStreams etc. is not included in the benchmark times. Additionally for each library best efforts are made to use them in the best possible way (e.g. reuse heavy weight objects if possible).