This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
What is the difference between Serializable and Externalizable in Java?
what is the difference between serialization and externalization in java?
Basically, the difference between Serializable and Externalizable is that with classes which implement Serializable, the serialization of the object is taken care of automatically, while classes that implement Externalizable is responsible for serializing itself, without the help of default serialization procedures.
There is more information provided in the API Specification for the Externalizable interface, and the Serializable interface. From the Externalizable interface documentation:
Only the identity of the class of an
Externalizable instance is written in
the serialization stream and it is the
responsibility of the class to save
and restore the contents of its
instances. The writeExternal and
readExternal methods of the
Externalizable interface are
implemented by a class to give the
class complete control over the format
and contents of the stream for an
object and its supertypes.
The Discover the secrets of the Java Serialization API article has a discussion on the Externalizable interface in the "Create Your Own Protocol: the Externalizable Interface" section.
I recommend reading an article called Understand When to Serialize v. Externalize Objects in Java that described the differences between serialization and externalization.
First is describes what serialization is:
The serialization of objects in Java
allows you to make a byte sequence
from any object that has implemented
the Serializable interface; it also
allows you to turn that byte sequence
back into an object.
Next it describes a situation in which externalization might be preferable to serialization:
There might be times when you have
special requirements for the
serialization of an object. For
example, you may have some
security-sensitive parts of the
object, like passwords, which you do
not want to keep and transfer
somewhere. Or, it may be worthless to
save a particular object referenced
from the main object because its value
will become worthless after restoring.
You can control the process of
serialization by implementing the
Externalizable interface instead of
Serializable. This interface extends
the original Serializable interface
and adds writeExternal() and
readExternal(). These two methods will
automatically be called in your
object's serialization and
deserialization, allowing you to
control the whole process.
I recommend reading the entire article, because the excerpts above do not cover the details. The article also contains several code snippets you might find useful.
Related
I am perplexed. I read some threads on stack-overflow regarding marker interfaces in JAVA.
On this thread it is written as:
Marker interfaces aren't 'identified by the JVM' at all. They're identified by the Java code that is interested in them, for example ObjectOutputStream, via the instanceof operator.
Then in comments, it is asserted that:
The implementation in ObjectOutputStream checks if the object has implemented the Serializable interface, if yes perform wirteObject(objectToBeSerialized). So even we can write a marker interface and write a code that checks if an object is an instance of that marker interface and take appropriate action on it then.
On another thread it is written as:
Only Serializable will mark an object as being compatible with Java's built-in serialization machinery.
You can create other empty interfaces, but they won't mean the same thing. Each interface is distinct, even if it defines the same set of methods.
So my question is can we make classes that use serialization without implementing corresponding JAVA's built in interface?
Or is it a special interface that is mandatory to be implemented?
(Asumme, I don't want to use instance of)
If I have main class, that is Serializible and create instances of other classes (no inheritance) that are not defined as being serializible, will the state of those classes be also preserved along with the state of the main class, if they are not static? I know that constructors of other objects are bypassed, but what about states? And yes, I did search SO and Google, but came out empty handed, so I hope some nice gent will clear this up quickly for me.
If there is a reference to an object that is not serializable, a NotSerializableException will be thrown.
When traversing a graph, an object may be encountered that does not
support the Serializable interface. In this case the
NotSerializableException will be thrown and will identify the class of
the non-serializable object.
Source: https://docs.oracle.com/javase/7/docs/api/java/io/Serializable.html
You may work around it, as some answers on SO suggest, e.g. Java Serialization with non serializable parts
This question already has answers here:
Why Java needs Serializable interface?
(13 answers)
Closed 8 years ago.
If we want to serialize an object, we can simply do the following implementation:
class MyClass implements Serializable
{
private static final long serialVersionUID = 12345L;
}
And no extra effort is needed to imperatively implement how the object will be written into and read from files. Java simply takes care of everything.
On the other hand, Externalizable does define explicit serialization and deserialization methods so we can program imperatively.
This leaves me the question: if no extra effort is needed for Serializable, what's the rationale to make it an interface that we have to implement to serialize/deserialize objects, instead of making it by default that every object can be serialized/deserialized?
When a programmer marks a class as Serializable he takes responsibility that if this class will change in future, programs which saved objects will be able to read them back to the updated class. Details are in Effective Java Item 74: Implement Serializable judiciously
There is another rationale. Did you ever notice that ObjectOutput.writeObject(Object obj) accepts Object, not Serializable? This is because it assumes that objects may be saved using different serialization mechanizms. Serializable means that object is supposed to be saved using Java standard serialization
Because:
Not all objects have meaningful semantics for this. Example: singleton object
Security. If you pass objects to someone else's code and they could always capture and transmit the object then there would need to be an opt out for security related code and there would be security bugs when people overlooked an object. So "off by default" is more secure.
The built in serialisation format writes out the classname for every object you write so it is very inefficient. Only use it for very simple cases with little data.
The default serialisation does not share data easily with code written in other languages so using a specific representation should be considered if data written today may need to be read by other software in the future. So it's not a good long term format.
The exact rules of how it works in all cases are not well remembered by all developers.
If you read the book Effective Java by Joshua Bloch it explains how tricky using the built in feature can be. Most developers avoid it for a lot of cases. This answer gives a good rule of thumb https://softwareengineering.stackexchange.com/a/240432/129659
The interface Serializable only works as a mask for identification.If every class
has the ability of being serialized ,then every class need to maintain the serialVersionUID in order to avoid version conflict.Also, it may cause the security problem : some one will use it as a way for creating new object,though
the object is not intended to be created by client code.Using Serializable interface is not safe.See Effective Java for more information.
I'd like to save a Java object to file (for unit testing later on). I have tried JSON but since I don't own the classes to the objects I'm serializing, deserialization becomes more effort than it is worth. (The getters and setters to the existing classes are overloaded with different types and Jackson cannot figure out how to deserialize the object)
Now I'm exploring other avenues (i.e. serializing to binary or some other format). I'm wondering if there is anything out there that can dump a Java object to binary/file so that deserialization is trivial. I understand you can do this with the Serializable interface, but again I don't own these classes which don't implement this interface so they cannot be modified.
You could also use XStream which does not depents on classes having implemented Serializable interface.
if they implement Serializable you do not need to own them (nor modify them), you can just write them to file using an ObjectOutputStream and read them back in with a ObjectInputStream
Assuming the classes have proper getters and setters you should have no issue doing this
You can also use Kryo. Benchmarks (here and here) say it is one of the fastest to serialize/deserialize and uses less space too. It also doesn't need Serializable to be implemented. That said, I have never used it personally.
New to Java. Learning it while working on an Android app. I am implementing a Comparator to sort a list of files and the android docs say that a Comparator should implement Serializable:
It is recommended that a Comparator implements Serializable.
This is the Serializable interface here.
I just want to sort a list of files. Why should I implement this or what even is the reason why it should be for any Comparator?
This is not just an Android thing, the Java SDK has the same recommendation:
Note: It is generally a good idea for comparators to also implement java.io.Serializable, as they may be used as ordering methods in serializable data structures (like TreeSet, TreeMap). In order for the data structure to serialize successfully, the comparator (if provided) must implement Serializable.
So the idea is that because a TreeMap is serializable, and the TreeMap can contain a Comparator, it would be good if the Comparator is also serializable. The same applies for all elements in the collection.
You can safely ignore this unless you use serialization in that way.
Serializeable is a blank interface. It does not contain any methods. So, to implement it, all you need to say is implements Serializable in a class. It's not a huge burden on you. If you extend Comparator, you don't even need to implement Serializable because the super class does that for you, and then you don't need to do anything at all to implement Serializable.
When something implements Serializable, that means the object can be turned into a byte array at will. This is used for transmission over the Internet, storage in a file, etc. Speaking very roughly, the way serialization works for an object, by default, is to take every object referenced by the object you're trying to serialize, turn each such object into a byte array (i.e. invoke serialization on it recursively), and concatenate the byte arrays to produce a byte array that represents the overall object.
Now, why should a Comparator implement Serializable? Let's say you wish to serialize a TreeMap or some other ordered Collection. The goal of serialization is to provide a complete representation of an object. Collections like TreeMap have a Comparator object in them, so to be able to produce a byte array that captures every aspect of such collections, you need to be able to save the Comparator as a byte array too. Hence, Comparator needs to be Serializable so that other things can be properly serialized.
This should help you out : http://docs.oracle.com/javase/7/docs/api/java/util/Comparator.html
Note: It is generally a good idea for comparators to implement java.io.Serializable, as they may be used as ordering methods in serializable data structures (like TreeSet, TreeMap). In order for the data structure to serialize successfully, the comparator (if provided) must implement Serializable.
To serialize an object in Java, both these conditions should be satisfied:
The class to which the instance belongs to must implement java.io.Serializable.
The members of the class should be serializable. If one or more of the members are not to be serialized, they should be marked as transient.
When any data structure uses a Comparator and you want that data structure to be serializable, point 2 (mentioned above) compels the comparator to implement serializable.
i have seen in Java 5 API
Link to java 5 APT
which stated that by implementing Comparator doesn't mean to implement Serializable interface anyways, so one has to explicitly pay attention to get Serializable in some customarily created Comparator class