I had to serialize a complex object, but one of its component was non-serializable ( a third party graph object), so I created a custom serializable version of this Graph class
Lists.transform() does perform lazily as you suspected. You could do one of
Lists.newArrayList(Lists.transform(...))
or, if you want an immutable version,
ImmutableList.copyOf(Lists.transform(...))
and then serialize the resulting list.
Lists.transform() returns a transformed view of the original list. From the Lists.transform() javadoc:
The returned list always implements Serializable, but serialization will succeed only when fromList and function are serializable.
When serializing the transformed view, you are actually serializing the original list, plus the function. In your case, it fails because your original list is not serializable (because it contains non-serializable graph elements). But it could also fail because the function does not implement serializable.
BTW, there is a little trick to create serializable functions without the verbosity. Instead of doing:
private static final class MyFunction extends Function<String, String> implements Serializable {
private static final MyFunction INSTANCE = new MyFunction();
@Override
public String apply(String input) {
return "[" + input + "]";
}
private Object readResolve() {
return INSTANCE;
}
private static final long serialVersionUID = 1;
}
You can use the enum singleton pattern, which is a lot less verbose, and gets you serialization for free (since enums are serializable). It also makes sure your Function is a singleton:
// enum singleton pattern
private enum MyFunction implements Function<String, String> {
INSTANCE;
@Override
public String apply(String input) {
return "[" + input + "]";
}
}
If you attempted to serialize a list returned from Lists#transform, the interface List itself is not Serializable.