Detailed explanation
In Java, transient is a field modifier whose built-in purpose is to exclude a field from default Java object serialization. Outside that mechanism, it does not change ordinary program behaviour: the field can still be assigned, read, and used in calculations like any other field. It does not affect visibility, thread safety, garbage collection, or object lifetime. For interviews, the central distinction is that transient describes serialization treatment, not how a field behaves during normal execution.
When ObjectOutputStream performs default serialization of a Serializable object, it writes eligible instance fields and skips transient fields. For the Session example, userId is included, while tempToken is excluded from the default serialized form. During ordinary Serializable deserialization, constructors and field initializers of serializable classes are not executed, so tempToken initially has its default value, null. A transient int would initially be 0, and a transient boolean would be false. Custom deserialization logic can then restore or recompute these values. Static fields are already excluded because they belong to the class rather than individual objects.
The modifier does not change Object.clone(): its normal shallow-copy behaviour copies transient fields too, including reference values. Reflection can also discover and access a transient field, subject to the usual access and module restrictions. There is one important nuance: reflection exposes the modifier through Field.getModifiers(), and Modifier.isTransient() can test it. Therefore, saying transient has absolutely no observable effect outside serialization is too broad; it remains metadata that libraries and tools can inspect and interpret.
Finally, transient is not a universal instruction to every serializer, persistence library, or JSON mapper. Such tools may honour it, ignore it, or use their own annotations and configuration. Even Java serialization can explicitly write a transient field through a custom writeObject method; Externalizable implementations control their own written data. Interviewers generally expect you to explain the default rule, separate it from cloning and reflection, and recognise that transient is neither a security boundary nor a guarantee that a value can never be persisted.
Key points to remember
- transient excludes an instance field from default Java serialization.
- It does not change normal reads, writes, visibility, or concurrency semantics.
- Object.clone() copies transient fields just like other fields.
- Reflection can access the field and inspect its transient modifier.
- Custom serialization and third-party frameworks can treat transient fields differently.
Common mistakes candidates make
- Claiming transient fields cannot be accessed through reflection or are skipped during cloning.
- Assuming a transient field's initializer runs during ordinary Serializable deserialization.
- Treating transient as encryption or a universal guarantee against persistence.
Likely follow-up questions
Can a transient field still be serialized?
Yes. A custom writeObject method can explicitly write its value, and a matching readObject method can restore it; transient only excludes it from default field serialization.
Does transient make a field thread-safe like volatile?
No. transient has no memory-visibility or synchronization semantics, whereas volatile establishes visibility and ordering guarantees for accesses to that field.
How can reflection detect a transient field?
Obtain its Field object and call Modifier.isTransient(field.getModifiers()). The field remains accessible under the usual reflection rules; transient itself imposes no access restriction.
Interview tip: Start with the default serialization rule, then distinguish normal execution and cloning from reflection-visible metadata and framework-specific behaviour.