AMF Serialization (followup Faster Serialization)
While i was looking for the fastest possible way to serialize Java Objects to byte-streams, i was comparing some serialization libs. With the help of Adobe Evangelist Cornel Creanga, i added AMF3 Serialization to the test.
Good things first: for my test-case, AMF3 turns out to be slightly faster and a little more compact than plain JDK6.
PlainSerializer: 999ms (Size: 639241 bytes) PlainSerializer: 862ms (Size: 639241 bytes) PlainSerializer: 779ms (Size: 639241 bytes) PlainSerializer: 781ms (Size: 639241 bytes) AMFSerializer: 775ms (Size: 554323 bytes) AMFSerializer: 680ms (Size: 554323 bytes) AMFSerializer: 661ms (Size: 554323 bytes) AMFSerializer: 656ms (Size: 554323 bytes)
This would be a good reason to use it if it was not for the following disadvantages:
- You need the to be serialized classes to be public.
- They need to have a no-arg Constructor being public as well.
- You have to expose the complete State of the Object by Getters/Setters
While the first two might be bearable, the third is a no-go. As AMF3 does not seem to look at the fields, a transient field will be serialized as well and if you missed a getter… well you know…
If you have dedicated Transfer Objects, that were just made for AMF3 Serialization, this might be fine. For me, the price to pay is way too high in comparison to about 10% performance improvement.
I am wondering, why the heck they tried to focus on properties instead of fields. As they call it Serialization, it´d be reasonable, to reflect the object´s complete state instead of its published properties. In fact, it would be even easier to reflect the Type-info etc. from fields instead of properties.