Dear Wiki user, You have subscribed to a wiki page or wiki category on "River Wiki" for change notification.
The "Serialization" page has been changed by PeterFirmstone: http://wiki.apache.org/river/Serialization?action=diff&rev1=1&rev2=2 It is of utmost importance that your Builder implementation doesn't become part of your public API and remains package private, to do this you need an abstract superclass with a static method that retrieves your builder implementation. + The major benefits of this pattern: + + * Decoupling of the serialized form from the implementation, allowing the use of final fields and preventing deserialization attacks. + * Only uses constructors to create instances, instead of implicit creation by deserialization. + * Allows the developer to change the serialized form, by replacing the builder with another implementation. + * By preserving the existing builder, but no longer utilising it, old serial data can be deserialized still, allowing an upgrade path. + * The Builder can even produce a different instance if you refactor your implementation, so you can remove old classes. + * You can have as many serial forms as you like in the form of old builders. + * By using a codebase, new builders and implementations can be dynamically downloaded by other nodes using earlier versions. + * Many implementations can share the same builder. + + Generics have been omitted for clarity. + === The Abstract Builder === {{{ public abstract class Builder { @@ -19, +32 @@ } public abstract Builder put(Object key, Object value); + + public abstract Builder putAll(Map map); public abstract Map build();
