Implement Serialization judiciously
Implementing default serialization is just two words away. One need to add implement Serializable with class name .
But this simple change comes with huge cost .
What is that cost :
1. Once you make a class serializable you loose the flexibility of making any change in the class.
What does that mean??
It means : Once an instance of serializable class in serialized , and after that you make some change in class implementing default serialization , you won't be
able to deserialize that object from serialized data stream. JVM generates serial version id for every serializable class and persist it with serialize stream So as
to validate at the time of deserialization if JVM still have same complied version of class as it was at the time of serialization. As class has been changed later
and that has changed the automatically generated version id , so id stored in stream does not match with id available in compiled class code and this
mismatch causes invalidClasscast exception.
So you need to be highly judicious to decide If implementing serialable is right for a class As making any change to that class, later, will cause problems in
getting those persisted data stream back in jvm
2. testing effort of making any change to class will be painstaking
You never know how many instances of that class are deserialized already , So for making any change you need to support the backward compatibility so that
every serialized instance can be perfectly deserialized. It's never an easy task As you might have to test a lot of data depending upon usage of that class.
So it has to be a very conscious decision to use default serialization otherwise lot of pain awaits you.
3. Security issue
An attacker can play with data stream serialized and can temper the state of object in such a way that at the time of deserialization a an instance with different
state is created which might cause lot of instability in the system and attacker can easily penetrate the system by intelligently tempering the data steam . This
can generate huge security concern depending upon severity and criticality of persisted data steam
4. You always need to make sure that a class available for inheritance must have accessible default constructor As no subclass would be able to implement
serializable if this is not done . So if you are taking decision of applying serializable on any class you need to take in consideration the structure of classes
making its inheritance hierarchy as well
So these are some of the reasons why you should take decision of implementing default serialization very judiciously . Custom serialization provide you a lot
of address to avoid many of these concerns. Custom serialization is discussed in detail in Item 75,76,77,78 .
please comment/question to discuss it further
Implementing default serialization is just two words away. One need to add implement Serializable with class name .
But this simple change comes with huge cost .
What is that cost :
1. Once you make a class serializable you loose the flexibility of making any change in the class.
What does that mean??
It means : Once an instance of serializable class in serialized , and after that you make some change in class implementing default serialization , you won't be
able to deserialize that object from serialized data stream. JVM generates serial version id for every serializable class and persist it with serialize stream So as
to validate at the time of deserialization if JVM still have same complied version of class as it was at the time of serialization. As class has been changed later
and that has changed the automatically generated version id , so id stored in stream does not match with id available in compiled class code and this
mismatch causes invalidClasscast exception.
So you need to be highly judicious to decide If implementing serialable is right for a class As making any change to that class, later, will cause problems in
getting those persisted data stream back in jvm
2. testing effort of making any change to class will be painstaking
You never know how many instances of that class are deserialized already , So for making any change you need to support the backward compatibility so that
every serialized instance can be perfectly deserialized. It's never an easy task As you might have to test a lot of data depending upon usage of that class.
So it has to be a very conscious decision to use default serialization otherwise lot of pain awaits you.
3. Security issue
An attacker can play with data stream serialized and can temper the state of object in such a way that at the time of deserialization a an instance with different
state is created which might cause lot of instability in the system and attacker can easily penetrate the system by intelligently tempering the data steam . This
can generate huge security concern depending upon severity and criticality of persisted data steam
4. You always need to make sure that a class available for inheritance must have accessible default constructor As no subclass would be able to implement
serializable if this is not done . So if you are taking decision of applying serializable on any class you need to take in consideration the structure of classes
making its inheritance hierarchy as well
So these are some of the reasons why you should take decision of implementing default serialization very judiciously . Custom serialization provide you a lot
of address to avoid many of these concerns. Custom serialization is discussed in detail in Item 75,76,77,78 .
please comment/question to discuss it further
No comments:
Post a Comment