XOR operations.

XOR has support as for POJO XML synchronization as for general Object’s life cycle. It includes persistence, initialization and validation. It is not necessary that those three will be demanded in a same process. Data could be altered not only during object persisting but at any time. In this case XOR initialization will be handy. In such event or just randomly object need to be validated and appropriate action need to be taken in case of failure. That is where XOR validation comes to help.

Sources and blog:

XOR operations


The initial goal of XOR was to support XML presentation of the object and allowing to modify it’s content via same XML presentation. Only the difference will be used for object’s part update. This ∆XML (delta xml) has same presentation as whole object’s XML presentation with stripped unrelated branches. In some circumstances ∆XML is not sufficient and special syntax on top or regular XML presentation will be applied. Like deleted=”true” attribute for delete operation.

XOR uses parameters for defining what kind of operation(s) need to be done:

Depend of parameters combination actual operations will be performed:

Create will be performed if

  1. Type is defined. In will be used for initialization.
  2. In has a root node mapped to created class and Object is null.

Create performs initialization after object creation. Validation is optional. It is assumed that initialization also does the validation internally.

Get performed when  Out parameter is present. Either for existing or created object.

Update modifies object with data from In XML. Initialization will be performed on altered field values and objects.



The goal of initialization is to keep object’s integrity. Temporary or depended from persistent (serialized) data shall be updated there. The perfect sample will be RegEx string as persistent data and dependent compiled Pattern:

class …
{   public    String  RegEx;
    transient Pattern CompiledRegEx;
    void initializeRegEx() { CompiledRegEx = Pattern.compile(RegEx)…

 Initialization called after object has been read or some of object`s content has been altered by XOR.

 It is different from constructor. Unlike constructor it could be called multiple times.  

XOR supports two initialization handler types:

  1. Obj.initializeXXX()for XXX field of object.
  2. Obj.initialize()  for whole object

While first serves updates of individual field members, the second called to set whole object integrity. There is no assumption in what order field’s initializers will be called, but object initializer (2nd) will be called last.

Result: Integrity updated, failures (initialization exceptions) added to Errors stack.

Note: Failure to initialize assumes no need for following validation. Initialization error has higher priority.

Test samples: ZZ.java, AI.java


In XOR it is a sequence of validation handlers calls during processing of objects and fields. The validation is optional and turned on by PerformValidation parameter. The sequence of handlers calls is same as initialization. The validation handler will be optionally called after matched initialization handler (if operation is create or update) or instead of initialization (GET operation). If initialization failed, it is assumed that validation is failed as well and do not performed.

As part of validation, the object’s integrity (which also has been done during initialization) shall be checked but not performed.

XOR supports two validation handler types:

  1. Obj.validateXXX()for XXX field of object.
  2. Obj.validate()  for whole object

While first serves validation of individual field members, the second called to verify the whole object integrity. There is no assumption in what order field’s validators will be called, but object validator (2nd) will be called last.

Note: Validation handlers shall not change object’s content (same as const C++ methods).

Test samples:
ZZ.java, AI.java
© Sasha Firsov, 2008