Hey Adam, I'd suggest you take a look at protobuf if you haven't done so already.
I've done a comparison some time ago over at http://sourceforge.net/apps/trac/lilith/wiki/SerializationPerformance and I use it extensively in Lilith. Protobuf is cross-platform and can be both forward- and backward-compatible if used with care (tag every message element optional and don't reuse IDs). Joern. On 29.08.2012, at 21:23, Adam Murdoch <[email protected]> wrote: > > On 30/08/2012, at 3:34 AM, Spencer Allain wrote: > >> I was tracing the network traffic between the gradle client process and the >> gradle daemon and was wondering if Java Serialized Objects make the most >> sense from a portability standpoint, especially since there is consideration >> of creating a native client to communicate with the daemon to mitigate JVM >> startup time concerns. >> >> Short of using something like Excelsior JET, a directly compiled executable >> will be implemented in some other language besides Java, precluding easy use >> of Serialized Objects. > > There are a few options we still need to spike for implementing a native > client in Java (e.g. java to c translation, gcj), but my guess would be that > we'll end up with a c based client. > > Ignoring the cross-language aspect, we want to move away from Java > serialisation for other reasons: better performance and better support for > schema changes. > > There are many places in Gradle that would benefit from improved > serialisation: > > * The client to daemon protocol would become portable, faster and > cross-version. > * The daemon registry would become cross-version, which means daemon > management can be cross-version (e.g. stop the daemon for all versions, the > daemon timeout can consider how many daemons are running across all versions). > * The worker process to Gradle protocol would become faster, which means > faster test execution and compilation. > * The artefact meta-data cache and the incremental build cache would become > smaller and faster. Everybody wins with this. > > I hope to start rolling out some of this in maybe the 1.3 or 1.4 release, but > initially focused on performance rather than portability. The current plan is > to start with the worker process protocol, as profiling suggests this should > benefit nicely from improved serialisation, and then move on to the caches. > But we might switch the order around if there's good reasons to. > > >> >> Two obvious portable data serialization formats are JSON and Google Protocol >> Buffers, each with different advantages and disadvantages. Not saying that >> either one should become the data transport protocol to/from the daemon, but >> just listing them as potential alternatives. >> >> Instead of replacing the current communications, alternatively, there could >> be a (potentially more limited) adapter for separate control on a different >> port that uses something other than Java Serialized Objects for the >> transport mechanism. > > We might do something like that to get the native client moving, but the goal > is to end up with a single portable protocol. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
