＋设为首页 ＋添加到收藏夹
often objects need to be serializable. this can be as easy as simply declaring that a class implements the serializable interface. but just because an object says its serializable doesnt necessarily mean that it will serialize (and deserialize) successfully. this article will explore what serialization is, how to prove that a purportedly serializable object can really be serialized, and how to redesign a nonserializable class to make it serializable.
the first question is: what is serialization and why do objects need to be serializable? the javadocs arent much help; they say what java.io.serializable does, but not what serialization is. to learn what it is, you must read the "java object serialization specification" in suns object serialization documentation (java.sun.com/products/jdk/1.2/docs/guide/serialization/"target="new">http://java.sun.com/products/jdk/1.2/docs/guide/serialization/). according to the spec, "the key to storing and retrieving objects in a serialized form is representing the state of objects sufficient to reconstruct the object(s)." so serializing an object converts it to a form that can be stored easily, and the stored form can easily be converted back into a java object again. the new object is essentially a copy of the original. furthermore, the object being serialized typically refers to other objects, a graph of objects that must be serialized and deserialized so that the entire structure is copied.
why do objects need to be serialized? the simple answer is persistence and distribution. one of the goals of serialization is to "support simple persistence of java objects," so object persistence schemes that simply want to store objects as blobs tend to use serialization and store the serialized form. (gemstone/j is an exception; it persists objects without serializing them, so it can persist any java object, even those that dont implement serializable.)
in the ejb technology, the javax.ejb.entitybean and javax.ejb.sessionbean interfaces extend serializable so that ejbs can easily be passivated and activated. to persist an entity bean field that is a complex object, the value is serialized.
another common use of serialization is as part of object distribution. a distributed object is one that is instantiated in one java virtual machine (jvm) but accessible from other virtual machines. if the object is not copied but is accessible remotely via remote method invocation (rmi), the arguments and result of the remote invocations must be marshalled (java.rmi.marshalledobject), which implements serializable so that the arguments and result can be serialized.
when using the java message service (jms), if you know that the consumer of your message will be another java application, you can send it an object using a javax.jms.objectmessage that contains the serialized object. even a throwable is serializable, so that it can be thrown from one vm to another like a marshaled object. thus if youre going to implement objects that can be distributed or persisted, youre going to need to make them serializable.
moving around in the byte stream
serialization is not unique to java. boss, the binary object streaming system, was a prominent feature of visualworks smalltalk since the early 90s. whenever you have objects, youll find a need to move them around using simple byte streams.
as common as serialization is, there are alternative ways to persist and distribute objects. java serialization ... 下一页