Effective Java

---

CHAPTER 12
SERIALIZATION
362
Running this program produces the following output, conclusively proving that
it’s possible to create two distinct 
Elvis
instances (with different tastes in music):
[Hound Dog, Heartbreak Hotel]
[A Fool Such as I]
You could fix the problem by declaring the 
favoriteSongs
field 
transient
,
but you’re better off fixing it by making 
Elvis
a single-element enum type
(Item 3). As demonstrated by the 
ElvisStealer
attack, using a 
readResolve
method to prevent a “temporary” deserialized instance from being accessed by an
attacker is fragile and demands great care. 
If you write your serializable instance-controlled class as an enum, Java guar-
antees you that there can be no instances besides the declared constants, unless an
attacker abuses a privileged method such as 
AccessibleObject.setAccessible
.
Any attacker who can do that already has sufficient privileges to execute arbitrary
native code, and all bets are off. Here’s how our 
Elvis
example looks as an enum:
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
private String[] favoriteSongs =
{ "Hound Dog", "Heartbreak Hotel" };
public void printFavorites() {
System.out.println(Arrays.toString(favoriteSongs));
}
}
The use of 
readResolve
for instance control is not obsolete. If you have to
write a serializable instance-controlled class whose instances are not known at
compile time, you will not be able to represent the class as an enum type.