We don't need it if we're implementing Serializable. So why this difference? How does it relate to the actual mechanism of Serialization?
3 Answers
A thorough explanation (although the grammar of the article might be improved) can be found on http://www.jusfortechies.com/java/core-java/externalization.php . The short answer, for future reference in case the linked page goes away:
Externalizable is an interface extending Serializable. Contrary to Serializable, though, objects are not restored by just reading the serialized bytestream, but the public constructor is called and only once the object is thus created, its state is restored. This makes restoring more efficient.
Edit: See also What is the difference between Serializable and Externalizable in Java? .
-
What public constructor are you talking about, given that this is an interface? Or are you referring to the article linked? – S.R.I Dec 25 '11 at 03:43
-
I'm refering to the same constructor the question is about, namely that of the implementing class. – jstarek Dec 25 '11 at 03:46
-
Ah, I misread. Thanks! Your answer would be more to the point if you mention about calling implementing methods right in the constructor. That said, your answer is better than mine. :) – S.R.I Dec 25 '11 at 03:51
-
@S.R.I. - the constructor of an Externalizable doesn't call the "implementing methods" for deserialization. The method (`readExternal`) is called on the newly created object *after the constructor returns*. – Stephen C Dec 25 '11 at 05:04
-
@StephenC, I fully agreed with jstarek here - it was a mistake on my part for not reading his answer right. We were both referring to the implementing class, that the OP referred to. Not any other way. – S.R.I Dec 25 '11 at 05:23
-
2This answer just repeats the fact, which bothers us in question. How can this be the answer? The question asks why frogs are green whereas all other reptiles are grey? You say that frogs are green and reptiles gray. How can this be the answer? I want to re-raise the question. – Val Sep 02 '12 at 14:07
-
This doesn't answer the question - why? – Aniket Thakur Jan 08 '14 at 08:58
This is primarily used for caching purposes. In order to deserialize across streams, you will need to spell out how you want your object to be deserialized, hence the two methods provided by the contract in Externalizable
interface: writeExternal
and readExternal
. Note that Externalizable
extends Serializable
, so you don't necessarily need to implement Serializable
interface (although it's a marker interface and there are no methods to be actually implemented).
For a sample implementation, have a look at MimeType.

- 1,860
- 14
- 31
A public no-arg constructor is needed while using Externalizable interface.
Because in case of Serializable
- readObject reads the required information from the ObjectInputStream
- Serialization uses reflection mechanism to get the necessary fields and their corresponding values.
- Serializable serializes all the data members (except static and transient).
But in case of Externalizable
- No reflection mechanism used.
- User doesn't serializes all data members.That's why to fetch values of the members which are not externalized public no arg constructor is required.

- 1,939
- 26
- 36