This would be a good addition to the AnalzeSerializablesJUnitTest. Banning non-DSFID DataSerializables in product code seems like a good idea.
On Fri, Nov 30, 2018 at 2:12 PM Michael Stolz <mst...@pivotal.io> wrote: > Jake thanks for bringing this up. > Could have been a big waste of effort if you hadnt. > > -- > Mike Stolz > Principal Engineer - Gemfire Product Manager > Mobile: 631-835-4771 > > On Nov 30, 2018 8:51 AM, "Jacob Barrett" <jbarr...@pivotal.io> wrote: > > > Devs, > > > > Please be careful with how you are serializing internal classes between > > servers and clients. While you may think you are safe if you simply use > > DataSerializable you are wrong, very very wrong. If you define your > > internal class as DataSerializable then when serialized the fully > qualified > > class name is serialized ahead of it to identify the class being > > serialized. This happens because there is no Instantiator for your > internal > > class, so it can’t use a number and falls back to the class name. If you > > rename or move the class later you will run into backwards compatibility > > issues that have to be resolved by transforming the string name back and > > forth to the new name. > > > > DataSerializable should be reserved only for user defined classes. Please > > use DataSerializableFixedID for internal classes. This method uses a > fixed > > integer to identify your class. Not only is it more efficient it also > > avoids issues with class or package renaming. > > > > Thanks, > > Jake > > > > >
