When we serialize objects, static members are not serialized, but if we need to do so, is there any way out?
+5
A:
The first question is why you need to serialize the static members?
Static members are associated with the class, not the instances, so it does not make sense to include them when serializing an instance.
The first solution is to make those members not static. Or, if those members are the same in the original class and the target class (same class, but possibly different runtime environments), don't serialize them at all.
I have a few thoughts on how one could send across static members, but I first need to see the use case, as in all cases that means updating the target class, and I haven't found a good reason to do so.
Kathy Van Stone
2009-06-17 16:12:13
suppose i want to count number of instance of a class like Car.and i am not using database .so in that case after application shutdown i need to store this information with other information.
Maddy.Shik
2009-06-18 05:11:57
Do you need to store that number directly? If you update the number as you deserialize each Car (by overriding readObject) it will correctly reflect the numbr of cars in the serialization.
Kathy Van Stone
2009-06-18 12:27:34
+1
A:
Static members belong to the class, not to the individual objects.
You should reconsider your data structure.
Thorbjørn Ravn Andersen
2009-06-17 16:13:59
+2
A:
You can control serialization by implementing:
private void writeObject(ObjectOutputStream out) throws IOException;
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;
There's a full description of serialization http://java.sun.com/developer/technicalArticles/Programming/serialization/.
As other answers have said, it doesn't really make sense to serialize statics as it's the object not the class you're serializing and needing to do so smells like you've got other issues with your code to me.
Nick Holt
2009-06-17 16:22:20
You can control serialisation, but that there is nowhere sensible to put static data because it doesn't make any sense in the context.
Tom Hawtin - tackline
2009-06-17 17:38:26
Since we don't know the context, we can't say whether it makes sense or not. For example, after using the default serialization, it might make sense to add the static member to the stream. At deserialization, one can set the static member if it is null, otherwise discard the serialized object.
erickson
2009-06-17 18:08:07
is there any wayout to serialize static members by serializing Class Object fr my class.
Maddy.Shik
2009-06-18 05:16:16
A:
Good answers and comments--don't do it. But how?
Chances are you would be best off creating an object to hold all your "Statics". That object should probably have any static methods from your class as well.
Every instance of your class can hold this other class--or if you really have to you can make it a singleton that any member can access.
After you do this refactor, you will find that it should have been done this way all along. You may even find that some of your previous design constraints that were bothering you at a subconsicionce level have vanished.
You'll probably find that this solution also solves other Serialization problems you hadn't even noticed yet.
Bill K
2009-06-17 16:26:35
+1
A:
Folks, static doesn't mean IMMUTABLE. For instance, I may want to serialize the whole state of the computation (yes, including static fields -- counters, etc) to resume later, after JVM and/or host computer restarted.
The right answer to that, as already said, is to use Externalizable, not Serializable, interface. Then you have a complete control on what and how you externalize.
Vladimir Dyuzhev
2009-06-17 16:33:00
If the state of the computation isn't embedded in the object you are serializing then you shouldn't be storing it as part of serialization of that object.
DJClayworth
2009-06-17 16:57:13
Think again. How about multithreaded genetic algorithms, for instance? Shared (static) storage is used to keep the registry of evaluated variants. Make it a singleton? Possible, but it has own drawbacks.
Vladimir Dyuzhev
2009-06-17 18:31:47
Yes. Make it a singleton. Serialize the singleton. Or, better, get rid of shared static storage, store it in an explicit context object.
Thilo
2009-06-18 11:08:01
... And then another bunch of purist will complain that Singleton is anti-pattern I should get rid of it too. As for "explicit context object", how do different threads access it? Via static methods? How's it better?
Vladimir Dyuzhev
2009-06-18 15:05:19
By "explicit" context object I meant passing it around explicitly to everyone who needs it.
Thilo
2009-06-19 04:00:44
A:
yes we can serialize the static variables but we can write our own writeObject() and readObject(). i think this can solves the problem
naresh
2009-12-27 04:31:52