The following code throws a NullPointerException
.
import java.io.*;
public class NullFinalTest {
public static void main(String[] args) thr
A transient final field used as a lock is null
Here are few facts about the transient variable:
- Transient keyword when used on an instance variable, will prevent that instance variable to be serialized.
- On De-serialization, the transient variable get to their Default values.....
Eg:
null
0
false,
etc.......So thats the reason you are getting a NullPointerException
, when deserializing it...
Any field that is declared transient
is not serialized. Moreover, according to this blog post, field values are not even initialized to the values that would be set by a default constructor. This creates a challenge when a transient
field is final
.
According to the Serializable javadoc, deserialization can be controlled by implementing the following method:
private void readObject(java.io.ObjectInputStream in)
throws IOException, ClassNotFoundException;
I came up with the following solution, based on this excellent StackOverflow answer:
import java.io.*;
import java.lang.reflect.*;
public class NullFinalTestFixed {
public static void main(String[] args) throws IOException, ClassNotFoundException {
Foo foo = new Foo();
foo.useLock();
ByteArrayOutputStream buffer = new ByteArrayOutputStream();
new ObjectOutputStream(buffer).writeObject(foo);
foo = (Foo) new ObjectInputStream(new ByteArrayInputStream(buffer.toByteArray())).readObject();
foo.useLock();
}
public static class Foo implements Serializable {
private final String lockUsed = "lock used";
private transient final Object lock = new Object();
public void useLock() {
System.out.println("About to synchronize");
synchronized (lock) {
System.out.println(lockUsed);
}
}
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
initLocks(this, "lock");
}
}
public static void initLocks(Object obj, String... lockFields) {
for (String lockField: lockFields) {
try {
Field lock = obj.getClass().getDeclaredField(lockField);
setFinalFieldValue(obj, lock, new Object());
} catch (NoSuchFieldException e) {
throw new RuntimeException(e);
}
}
}
public static void setFinalFieldValue(Object obj, Field field, Object value) {
Exception ex;
try {
field.setAccessible(true);
Field modifiers = Field.class.getDeclaredField("modifiers");
modifiers.setAccessible(true);
modifiers.setInt(field, field.getModifiers() & ~Modifier.FINAL);
field.set(obj, value);
return;
} catch (IllegalAccessException e) {
ex = e;
} catch (NoSuchFieldException e) {
ex = e;
}
throw new RuntimeException(ex);
}
}
Running it results in the following output (no NullPointerException
):
About to synchronize
lock used
About to synchronize
lock used
As pointed out before, the declaration below does not work as one might expect:
transient final Object foo = new Object()
The transient
keyword will prevent the member from being serialized. Initialization with a default value is not honored during deserialization, therefore foo
will be null
after deserialization.
The final
keyword will prevent you from modifiying the member once it has been set. This means you're stuck with null
forever on a deserialized instance.
In any case you will need to drop the final
keyword. This will sacrifice immutability, but should not usually be an issue for private
members.
Then you have two options:
readObject()
transient Object foo = new Object();
@Override
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
in.defaultReadObject();
foo = new Object();
}
When creating a new instance, foo
will be initialized to its default value. When deserializing, your custom readObject()
method will take care of that.
This will work on JRE but not on Android, as Android's implementation of Serializable
lacks the readObject()
method.
Declaration:
transient Object foo;
On access:
if (foo == null)
foo = new Object();
doStuff(foo);
You would have to do this wherever in your code you access foo
, which may be more work and more error-prone than the first option, but it will work on JRE and Android alike.