I've seen several instances in Geode code where someone has modified a
class or interface to make an object Serializable in order to make
distributed unit testing easier.
In all of these instances people have made a class implement
DataSerializable, which extends Serializable. This allowed them to pass
these objects from one JVM to another in distributed tests:
final RegionAttributes attr = new RegionAttributesFactory().create();
vm.invoke(() -> { do something with attr });
That "invoke" is an RMI call that is going to java-serialize "attr".
It's not going to use DataSerializable serialization and invoke
toData/fromData methods. RegionAttributesImpl has plenty of instance
variables that aren't serializable when they're not null, so it's just
by luck that this worked at all.
Instead of changing a Geode class like that you should create the
attributes object in the target JVM:
vm.invoke(() -> {
RegionAttributes attr = new RegionAttributesFactory().create();
do something with attr
});
Use of java serialization with classes that are DataSerializable is an
iffy practice. Let's stop doing it.
