This post originated from an RSS feed registered with Java Buzz
by Wilfred Springer.
Original Post: Preon versus Google Protocol Buffers
Feed Title: Distributed Reflections of the Third Kind
Feed URL: http://blog.flotsam.nl/feeds/posts/default/-/Java
Feed Description: Anything coming to my mind having to do with Java
Preon was mentioned in a discussion about implementing Google Protocol Buffers in JBoss. The author considers Preon to be slightly off-topic, but perhaps interesting. It makes you wonder if Preon actually bears some similarity with Google Protocol Buffers. Let's take a look at that.
Preon like Google Protocol Buffers is about marshalling between the in-memory representation of a data structure, and its binary encoded representation. In that way, they are similar.
Google Protocol Buffers is not just about encoding and decoding data: it also defines an RPC model. Preon does not; it's about the binary encoded representation only. That way, they are different.
Google Protocol Buffers already has encoding implemented. For Preon, it's clear how it should be done, but since it is not backed by a large corporation yet (anyone?), I haven't been able to work on encoding yet. In that sense, they are different.
Google Protocol Buffers relies on .proto files for defining the data structure. Preon doesn't. Preon allows you to define the mapping from a Java class to its binary encoded representation inside the class itself, relying on annotations. In that sense, they are different.
Google Protocol Buffers generates source code. Preon doesn't. Preon builds the entire Codec at runtime. In Preon, the only objects that you have to deal with are the objects you wrote yourself. In that sense, Google Protocol Buffers and Preon are different.
Google Protocol Buffers supports multiple languages. Now this is an interesting one. Since the Codec constructed by Preon captures exactly how the data is represented in a binary way, it should be fairly straightforward to generate code from it for different languages. Now, that would of course be a little unusual, but nevertheless doable. It that sense, they are currently different.
Google Protocol Buffers is not extensible. Well, it is extensible, but not in the way Preon is extensible. It does not allow you to use other types of compression techniques, unless you do that in the application layer. (Let's just say, accept a byte array, and interpret that byte array at he compressed representation of something else.) Preon is extensible. It's like allowing the protocol buffer language to be extended to support new types. In Preon, you can create your own CodecFactory, and hook that up with the framework. From that point on, sky is the limit. In that sense, they are different.
Google Protocol Buffers supports decoding the full data structure all at once, in a single pass. Preon was designed to decode data just in time, only if we need it. That was done deliberately. Preon originates from decoding map data. You don't want to decode a full map into memory all at once. It would blow up the heap, if you need to stay within the boundaries of a Java 32-bit VM. So Preon will try really hard not to decode all data all at once. In that sense, Google Protocol Buffers and Preon are completely different animals.
Preon allows you to define dependencies between different fields, and have that influence the way data is decoded. In that sense, it's different from pretty much anything else out there - apart from the Flavor derivatives. So if you first read a numeric attribute, then you can reuse that attribute further along down the road, for instance by interpreting it as the number of elements in an array Preon has to read. For media content, this is fairly common. In typical serialization mechanisms, this is pretty uncommon. The expressions you can use to define these dependencies can be as complicated as you like. In that sense, Google Protocol Buffers and Preon are totally different.
In summary, Google Protocol Buffers and Preon are quite different, and address different needs. Preon is better suited for decoding existing media types. Google Protocol Buffers is better suited for integration projects.
Previous Topic
