When serializing JID instances in a cluster, do not use the (expensive) JID constructor
Constructing a JID class via the regular constructors is a resource intensive task (the stringprepping that occurs requires a lot of CPU-cycles). This should be avoided when needed.
When a JID instance is moved between cluster nodes, it is safe to assume that the original instance got node-prepped. The marshalling/unmarshalling (between cluster nodes) does not need to repeat this process. Currently, a String representation is serialized/deserialized and fed to the (resource intensive) JID constructors. As the JID class is Serializable itself, there is a lot to be gained here.
In revision 13425, the way a JID was Externalized was changed. Instead of using its string representation, the Serializable interface of the JID class is now utilized.