TL;DR: Serialization is a non-trivial contract to support, so we don't make things serializable unless absolutely necessary.
In the early days of Cayenne we wanted almost everything to be serializable: 1. Contexts and objects (and everything they rely upon) was serializable for convenience, as most frameworks of the day would rely on sessions, and those could be clustered / persisted. This wasn't particularly efficient, as each session could drag around tens of megabytes of data or more, but it was unavoidable. It was also impossible to make transparent, so you needed an explicit step on deserialization reattaching objects to the stack. 2. Metadata (DataMap, etc) and Query objects were made Serializable because of Cayenne ROP. As the things have evolved in the industry in the direction of stateless services (and ROP having a good chance to get deprecated soon), my hope is that we can gradually do away with serializability constraints through the stack (perhaps keeping #1 as an option). So most new APIs are not serializable by default. With the Property class, it won't be the end of the world if we make it Serializable, but it feels like under "normal" conditions this should not be needed. An object holding it may actually implement its own read/writeObject to save it as a String. Hope that's not too much trouble. Andrus > On May 15, 2019, at 3:36 AM, Lon Varscsak <lon.varsc...@gmail.com> wrote: > > Not really. I do understand transient, but I'd have to store other data to > be able to recreate the Property when needed. It just seems like an > unnecessary step unless there's a reason that Propertys aren't serializable. > > -Lon > > On Tue, May 14, 2019 at 3:59 PM John Huss <johnth...@gmail.com> wrote: > >> Does this help? >> >> >> https://stackoverflow.com/questions/910374/why-does-java-have-transient-fields >> >> >> On Tue, May 14, 2019 at 5:20 PM Lon Varscsak <lon.varsc...@gmail.com> >> wrote: >> >>> Any reason we can't have Property be Serializable? I have situations >> where >>> I will keep references to properties in a web page (like for dynamic >>> columns) and my framework serializes those things (or errors out if it's >>> not serializable). I originally solved this with having my own Subclass >> be >>> Serializable, but now with protected constructors I'm getting errors. >>> >>> Thoughts? >>> >>> -Lon >>> >>
