Editing Serialization (section)

===Java===
Java provides automatic serialization which requires that the object be [[Marker interface pattern|marked]] by implementing the {{Javadoc:SE|package=java.io|java/io|Serializable}} [[interface (Java)|interface]]. Implementing the interface marks the class as "okay to serialize", and Java then handles serialization internally. There are no serialization methods defined on the <code>Serializable</code> interface, but a serializable class can optionally define methods with certain special names and signatures that if defined, will be called as part of the serialization/deserialization process. The language also allows the developer to override the serialization process more thoroughly by implementing another interface, the {{Javadoc:SE|java/io|Externalizable}} interface, which includes two special methods that are used to save and restore the object's state.<br /> There are three primary reasons why objects are not serializable by default and must implement the <code>Serializable</code> interface to access Java's serialization mechanism.<br />Firstly, not all objects capture useful semantics in a serialized state. For example, a {{Javadoc:SE|java/lang|Thread}} object is tied to the state of the current [[JVM]]. There is no context in which a deserialized <code>Thread</code> object would maintain useful semantics.<br />Secondly, the serialized state of an object forms part of its class' compatibility contract. Maintaining compatibility between versions of serializable classes requires additional effort and consideration. Therefore, making a class serializable needs to be a deliberate design decision and not a default condition.<br />Lastly, serialization allows access to non-[[Transient (computer programming)|transient]] private members of a class that are not otherwise accessible. Classes containing sensitive information (for example, a password) should not be serializable nor externalizable.<ref name=Bloch>{{cite book | title= "Effective Java: Programming Language Guide" |last=Bloch| first=Joshua| publisher=Addison-Wesley | edition=third | isbn=978-0134685991| year=2018}}</ref>{{rp|339–345}} The standard encoding method uses a recursive graph-based translation of the object's class descriptor and serializable fields into a byte stream. [[Primitive data type|Primitive]]s as well as non-transient, non-static referenced objects are encoded into the stream. Each object that is referenced by the serialized object via a field that is not marked as <code>transient</code> must also be serialized; and if any object in the complete graph of non-transient object references is not serializable, then serialization will fail. The developer can influence this behavior by marking objects as transient, or by redefining the serialization for an object so that some portion of the reference graph is truncated and not serialized.<br /> Java does not use constructor to serialize objects. It is possible to serialize Java objects through [[JDBC]] and store them into a database.<ref>{{cite web|url=https://asktom.oracle.com/pls/apex/f?p=100:11:0::::p11_question_id:1285601748584|title=Ask TOM "Serializing Java Objects into the database (and ge..."|website=asktom.oracle.com}}</ref> While [[Swing (Java)|Swing]] components do implement the Serializable interface, they are not guaranteed to be portable between different versions of the Java Virtual Machine. As such, a Swing component, or any component which inherits it, may be serialized to a byte stream, but it is not guaranteed that this will be re-constitutable on another machine.