JavaBean Why do I have to implement the Serializable interface?

The "object serialization" of Java allows you to convert an object that implements the serializable interface into a set of byte, so that you can restore the byte data and reconstruct that object accordingly. This is true even in cross-network environments, which means that the serialization mechanism can automatically compensate for differences in operating systems. That is, you can create a key object on your Windows machine, serialize it, then upload it to the UNIX machine via the network, and then rebuild there. You don't have to worry about how the data is represented on different platforms, in byte order, or in any other detail.

Object serialization itself is interesting because it allows you to implement "lightweight persistence (lightweight persistence)". The so-called persistence is that the life cycle of an object is not determined by whether or not the program is running; The object is still alive between the two invocations of the program. You can achieve the persistence effect by writing the serialized object to disk and then reading it again when the program is running again. The reason for being "lightweight" is that you can't use keywords like "persistent" to define an object directly, and then let the system handle all the details (though it may be in the future). Instead, you must explicitly serialize (serialize) and serialize (deserialize). If you need a more formal persistence feature, consider a tool such as Java Data Object (JDO) or Hibernate (http://hibernate.sourceforge.net).

The reason to include object serialization in a language is to use it to implement two important functions. Java's remote method invocation (invocation) allows you to invoke objects on other machines as you would call objects on your own machine. When you pass a message to a remote object, you need to pass the object serialization to transfer the parameters and return values. RMI will be discussed in the thinking in Enterprise java.

We'll talk about JavaBean in the 14th chapter. For JavaBean, object serialization is also essential. The state information for a bean is usually configured at design time. These state information must be saved for use when the program is started, and object serialization is responsible for this work.

Serializing an object is still relatively straightforward, as long as it implements the Serializable interface (this is a "tagged interface (tagging interface)", there is no method). However, when the language introduces serialization concepts, many of its standard class library classes, including Primitive's wrapper class, all container classes, and many other classes, will change accordingly. Even the class object will be serialized.

To serialize an object, you must first create a outputstream and then insert it into the objectoutputstream. At this point, you can write the object to OutputStream using the WriteObject () method. When reading, you have to embed the InputStream into the ObjectInputStream and then call the ReadObject () method. But it's just a reference of an object, so you have to pass it before you use it.

The smartest thing about object serialization is that it not only saves a copy of the object, but also follows the object's reference, saves the object it references, and then keeps track of the reference of those objects, and so on. This situation is often referred to as the "object Net" that a single object is connected to. This mechanism covers not only the object's member data, but also the reference within the array. Writing a program that tracks these links can be a very painful task if you want to implement object serialization yourself. However, the object serialization of Java can do this precisely, without a doubt, its traversal algorithm is optimized.

---------------------------------------------------------------------

Classes that implement the Java.io.Serializable interface are serializable. Classes that do not implement this interface will not be able to serialize or deserialize their any state.

All subclasses of a serialized class are themselves serializable. This serialized interface has no methods and no fields, and is used only to identify the semantics of serialization. Allows the serialization of a subtype of a non-serialized class, the subtype can assume the state responsible for saving and restoring the domain of the parent type's public, protected, and (if accessible) package. As long as the class (extension) has a parameterless constructor, which initializes its state, the subtype can assume the above duties. In this case, it is an error to declare a serializable class. This error will be detected at run time. That is, you can save the object to a byte stream, and then you can recover!

For example:integer implements the serializable, so you can write an integer object with IO to the file, and then can read from the file, such as when you start to write the object's Intvalue () is 5, then read it is also 5. This reflects the role of the ordered class, which is the object used to transfer the class.

When a javabean is instantiated within a construction tool and connected to another bean, all its states should be saved, and the next time it is load into the construction tool or at run time, it should be the last modified information. To be able to do this, save the information for some of the bean's fields and make it implement the Java.io.Serializable interface when defining the bean. For example:

public class Button implements Java.io.Serializable {...}

Information about the fields in the bean that implements the serialized interface is automatically saved. What do you mean if you don't want to save some words (the information about the fields in the bean here is automatically saved?) How is this auto-save implemented? ）

The information for the segment can be prefixed with the transient or the static keyword before these fields, and the information for the transient and static variables cannot be saved. In general, all properties that are exposed by a bean should be saved or optionally saved in the internal state. When the bean developer modifies the software, it can add fields, remove references to other classes, change the private, protected, or public state of a field without affecting the storage structure relationship of the class. However, when you delete a field from a class, change the position of a variable in the class system, convert a field to transient/static, or the original is transient/static, and now change to another feature, it will cause changes in the storage relationship.

The so-called Serializable, is the Java provides the common data saving and reading interface. Where to read from and where to save is hidden behind the function parameters. In this way, any type that implements the serializable interface can be saved to a file or sent to another location as a data stream over the network. You can also use pipelines to transfer to other programs in your system. This greatly simplifies the design of the class. as long as the design of a save a read function can solve all the problems mentioned above.



Transfer from http://www.cnblogs.com/hoobey/p/5426727.html

JavaBean Why do I have to implement the Serializable interface?