Follow up on this; I have now removed the Serialization code in the ValueBuilder prototype handling, and doing a shallow clone instead.
IMPORTANT: This means that all properties of a ValueComposite MUST BE IMMUTABLE. In reality, this has always been implied, for instance Collections classes in Properties are wrapped in Collections.unmodifiableXyz() calls and Property can have ValueComposites, but regular objects are high discouraged, although might still be supported. In 3.0, I want to remove the possibility to put POJO into Property<?> of ValueComposites and narrow down the exact types to support (which will all can be ensured to be Immutable). This works for me, and I have merged these and a bunch of other changes into 'develop' branch, for every to take a look. Cheers Niclas On Fri, Jun 5, 2015 at 2:48 PM, Niclas Hedhman <[email protected]> wrote: > > The more I dig in the prototype support, the more I think it was a bad > idea in general. > > I am leaning towards dropping the prototype() concept in Value building in > 3.0 and operate on a protoInstance instead, just like is done in Entities. > > Reason; The current implementation is really slow, because serialization > occurs. And that is even if I don't care about prototyping at all. > > Alternatively, keep prototyping as is, but introduce a newValueBuilder() > with > > The semantics are unclear, since we don't block the immutability of > property values. if we did that, stop supporting mutable types, and > wrapping Collections.unmodifiableXyz(), because then a shallow clone of the > prototype would be enough, instead of the current deep clone that occurs. > > ANybody has any thoughts on this? > > Cheers > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
