I came across a mock question which is as follows -
Which of the following is true ? A. transient methods must be static B. native methods violate Java's platform independence. C. static methods cannot be protected D. transient variables may not be final or static
Answer says : B and D are correct. The modifier transient can only be applied to variables and not methods, hence A is incorrect. B is true because native methods execute code which lies entirely outside the Java Virtual Machine, this code is compiled for a specific targeted machine and hence makes the application platform independent thereby violating Java's platform independence. C is incorrect as there is nothing wrong in static methods being protected. D is correct as transient variables cannot be final or static.
But, as far as my knowledge is concerned and after i tried this out on the JDK 1.4 compiler i found that we can declare transient variables are final or static , also as final and static without any compilation / execution problems.
Is there some thing that i misunderstood from the question and answer or is the answer provided in the mock exam incorrect ?
Using transient you are saying that it should not be used when serializing.
static: Serialization does not apply to classes but only to objects, so using static is in combination with transient is bogus.
transient: This is not as easy to explain. I can't find an explanation for this is the JLS, but it has to do with the fact that final fields have to be initialized exactly once and that while deserializing the constructor, i.e. the place where the initialization code is, is not invoked.
I am trying to explain why you can't combine transient with static and/or final. However, after searching the JLS and trying some examples I am starting to think that final+static+transient, although not always as useful, is just fine.. [ May 27, 2006: Message edited by: Dick Eimers ]
The modifier transient can be applied to field members of a class. It is used during serialization. Every field marked as transient will not be serialized.
Now, serialization is concerned with the object's current state. Hence, static member fields, also, are ignored during serialization, because they do not belong to the serialized instance, but to the class.
Well, as you conclude now, there is no point in declaring a static member field as transient, since transient means: "do not serialize", and static fields would not be serialized anyway.
Surprisingly, the java compiler does not complaint if you declare a static member field as transient. However, as another rancher said, there is no point in doing so.
On the other hand, an instance member field declared as final could also be transient, but if so, you would face a problem a little bit difficult to solve: As the field is transient, its state would not be serialized, it implies that, when you deserialize the object you would have to initialize the field manually, however, as it is declared final, the compiler would complaint about it.
For instance, maybe you do not want to serialize your class' logger, then you declared it this way:
private transient final Logger logger = Logger.getLogger("jedi");
Now, when you deserialize the class your logger will be a null object, since it was transient. Then you shouldinitialize the logger manually after deserialization or during the deserialization process. But you can't, because logger is a final member as well.
There is just one exception to this rule, and it is when the transient final field member is initialized to a constant expression as those defined in the JLS 15.28. Hence, field members declared this way would hold their constant value expression even after deserializing the object. I guess that is so because the value of the final field is actually a constant expression as described by the JLS.
This example shows transient final fields that would hold their constant values even after deserializing the object:
public transient final String name = "Anakin"; public transient final int age = 20;
Have you go the point, comrade? [ May 28, 2006: Message edited by: Edwin Dalorzo ]