Thanks for clarification. I would say use Java serialization as a default, and make it easy to plugin Hessian and Protostuff as separate modules.
A. > On May 5, 2016, at 5:39 PM, Savva Kolbachev <s.kolbac...@gmail.com> wrote: > > Hi Andrus, > >> So which one is the default, Hessian or Java? > We still use Hessian for serialization by default > https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/org/apache/cayenne/rop/HessianROPSerializationService.java > But we use java.net.URLConnection for establish connection and sending > messages from client to server > https://github.com/apache/cayenne/blob/master/cayenne-client/src/main/java/org/apache/cayenne/rop/http/HttpROPConnector.java > So we have escaped from Hessian only in connectivity layer. > >> I don't have a problem with Protostuff being a recommended default, but > for dependency management purposes I'd rather we split all third-party > integrations in separate modules, and use whatever provider is hooked up in > runtime. Kind of what we do with Joda/Java8 extensions. > I already did it in this way. I created separate module for Protostuff > serialization. > > As Hessian serialization has some troubles with Java8 types and provide > less efficient serialization than Protostuff, I suggest to use Protostuff > as default serialization service or to use Java serialization. So I just > suggest to escape from Hessian :) > > 2016-05-05 19:41 GMT+03:00 Savva Kolbachev <s.kolbac...@gmail.com>: > >> Hi Ari, >> >> Looks like Protostuff works faster than Protobuf in some cases. For >> example Serializers (no shared refs) and Cross Lang Binary Serializers >> sections here http://hperadin.github.io/jvm-serializers-report/report.html >> >> In our case we need to serialize graph of objects (Full Object Graph >> Serializers section in link above). Protobuf can't do it out of the box >> but Protostuff can. In my implementation I use protostuff-graph-runtime >> which generates a schema from objects at runtime and caches it. >> >> Protostuff schema is something like .proto files but in Java: >> http://www.protostuff.io/documentation/schema/ >> Runtime schema: http://www.protostuff.io/documentation/runtime-schema/ >> >> As you could see in benchmarks there is a small difference in efficiency >> between protostuff-graph and protostuff-graph-runtime. The ser/deser >> overhead is related to runtime schema generation. The size penalty is that >> Protostuff adds class name for objects and than uses those for find >> appropriate classes via reflection. >> Hessian also adds fields names so the size of Hessian serialization is >> much bigger. In my small example with selection of 6 objects Hessian >> serialization size is more than 2400 bytes while Protostuff runtime is >> about 800 bytes. >> >> If we don't want to have ser/deser and size overhead we could find a way >> to generate schemas via Velocity. And we should provide schemas for some >> Cayenne classes. But it will require a lot of efforts. >> >> >> 2016-05-05 13:44 GMT+03:00 Aristedes Maniatis <a...@maniatis.org>: >> >>> On 5/05/2016 7:35pm, Savva Kolbachev wrote: >>>> Protostuff (licensed under Apache 2.0 licence) is based on Google's >>>> Protocol-Buffers (Protobuf) but has some optimizations and some cool >>> things >>>> like runtime serialization graph of objects (like Hessian). It also >>> could >>>> generate schema on runtime so we shouldn't define .proto files although >>> it >>>> might increase efficiency. It works faster than Hessian and could handle >>>> Java8 Date and Time types. Here is some benchmarks. Take a look at Full >>>> Object Graph Serializers section. >>>> http://hperadin.github.io/jvm-serializers-report/report.html >>>> https://github.com/eishay/jvm-serializers/wiki >>> >>> According to those benchmarks there appears to be no performance or size >>> penalty to using protostuff over protobuffers. Am I reading that right? >>> >>> I don't really understand... doesn't the serialiser have to construct a >>> .proto definition and then include it in the message? So shouldn't it be >>> faster/smaller to predefine these? >>> >>> If we did, we could create them with velocity in the same way we create >>> Java _superclasses today. Fairly trivial I'm guessing. >>> >>> Ari >>> >>> >>> -- >>> --------------------------> >>> Aristedes Maniatis >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>> >> >> >> >> -- >> Thanks and Regards >> Savva Kolbachev >> > > > > -- > Thanks and Regards > Savva Kolbachev
