Why does Java have transient variables?
To allow you to define variables that you don't want to serialise.
In an object you may have information that you don't want to serialise/persist (perhaps a reference to a parent factory object), or perhaps it doesn't make sense to serialise. Marking these as 'transient' means the serialisation mechanism will ignore these fields.
A transient variable is a variable that may not be serialized.
One example of when this might be useful that comes to mind are variables that make only sense in the context of a specific object instance and which become invalid once you have serialized and deserialized the object. In that case it is useful to have those variables become null instead so that you can re-initialize them with useful data when needed.
It's needed when you don't want to share some sensitive data that go with serialization.
I guess it's pretty rudimentary those days. Even for serialization control you'd better use annotations.
The transient
keyword in Java is used to indicate that a field should not be serialized.
From the Java Language Specification, Second Edition, Section 8.3.1.3 transient
Fields:
Variables may be marked transient to indicate that they are not part of the persistent state of an object.
For example, you may have fields that are derived from other fields, and should only be done so programmatically, rather than having the state be persisted via serialization. Here's an GalleryImage
class which holds and image and a thumbnail:
class GalleryImage implements Serializable
{
private Image image;
private transient Image thumbnailImage;
private void generateThumbnail()
{
// Generate thumbnail.
}
private void readObject(ObjectInputStream inputStream)
throws IOException, ClassNotFoundException
{
inputStream.defaultReadObject();
generateThumbnail();
}
}
In this example, the thumbnailImage
is a thumbnail image that is generated by invoking the generateThumbnail
method.
The thumbnailImage
field is marked as transient
, so only the original image
is serialized rather than persisting both the original image and the thumbnail image. This means that less storage would be needed to save the serialized object. (Of course, this may or may not be desirable depending on the requirements of the system -- this is just an example.)
At the time of deserialization, the readObject
method is called to perform any operations necessary to restore the state of the object back to the state at which the serialization occurred. Here, the thumbnail needs to be generated, so the readObject
method is overrided so that the thumbnail will be generated by calling the generateThumbnail
method.
For additional information, the Discover the secrets of the Java Serialization API article from the Sun Developer Network has a section which discusses the use of and presents a scenario where the transient
keyword is used to prevent serialization of certain fields.
Serialization systems other than the native java one can also use this modifier. Hibernate, for instance, will not persist fields marked with either @Transient or the transient modifier. Terracotta as well respects this modifier.
I believe the figurative meaning of the modifier is "this field is for in-memory use only. don't persist or move it outside of this particular VM in any way. Its non-portable". i.e. you can't rely on its value in another VM memory space. Much like volatile means you can't rely on certain memory and thread semantics.
Then why Hashtable attribute (private transient Entry[] table;) is serialized?
"transient" is used to indicate that a class field don't need to be serialized. Probably the best example is a 'Thread' field. There's usually no reason to serialize a 'Thread', as it's state is very 'flow specific'.