Classes that implement the Externalizable interface must provide the readExternal() and writeExternal() methods. These methods have package or public access, and so they can be called by trusted and untrusted code alike. Consequently, programs must ensure that these methods execute only when intended , and that they cannot overwrite the internal state of objects at arbitrary points during program execution.
...
This noncompliant code example allows any caller to reset the value of the object at any time , because the readExternal() method is necessarily declared to be public and lacks protection against hostile callers.
...
This compliant solution protects against multiple initialization through the use of a boolean Boolean flag that is set after the instance fields have been populated. It also protects against race - conditions by synchronizing on a private lock object (see LCK00-J. Use private final lock objects to synchronize classes that may interact with untrusted code).
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="7d808123190e0cfb-c4e23c41-43654f8a-ac46bb95-09286f4a80058e713ca33314"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] |
| ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4a65f2ba6db6d5c0-d846c921-495f4cbe-90aba937-bda0ec1eea751c333e9846eb"><ac:plain-text-body><![CDATA[ | [[Sun 2006 | AA. Bibliography#Sun 06]] | "Serialization specification: A.7 Preventing Overwriting of Externalizable Objects" | ]]></ac:plain-text-body></ac:structured-macro> |
...