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
