Fast-serialization

Home

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

features:

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)
optional full featured serialization to/from JSON
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

Maven, Download

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 version

current:

<dependency>
    <groupId>de.ruedigermoeller</groupId>
    <artifactId>fst</artifactId>
    <version>2.35</version>
</dependency>

older version (1.6 build, slightly faster, less features, serialization probably more stable)

<dependency>
    <groupId>de.ruedigermoeller</groupId>
    <artifactId>fst</artifactId>
    <version>1.63</version>
</dependency>

State of this project

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).

Documentation

see Wiki

Also see this blog post.

Limits

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
direct reading/writing a blocking stream (e.g. socketinputstream): see answer and example in this issue

Benchmark

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).

current results