Monday 23 April 2012

Java Interfaces in Google Protobuf

Google Protobuf: Excellent idea, well executed but only if.....

[I have put this project on hold as I'm occupied with something else. I was concerned with enums in messages and composition of messages. I also came across Protostuff which has its own .proto interpreter and uses reflection to inject messages in to POJOs. You can also use Annotations to define the .proto message spec. TJ]

A proposal to add interface decoration to Protobuf generated messages.


Google Protobuf is a language that defines how one encodes messages on a transport.

Like everything Google - it is well thought out, not over designed and intelligently implemented. It is target language agnostic, efficient and allows for managed upgradeability.

The .proto message compiler (protoc) only creates rich (final) Message classes. These contain the immutable messages and access to builders for creating new messages.

Java Interfaces

Perhaps the best language feature of Java (there are many more...) is the Interface. It is a traditional implementation-free definition of the contract that an implementing object must provide.

It has a number of advantages including:

  • Using an interface means that you can change the implementation but maintain the contracted functionality;
  • You can write collaborators that work on objects that implement the interface without any other knowledge or dependencies on the implementation;
  • When testing classes that use the interface you can stub easily stub or mock out the interfaced object;
  • And many more.

Using protobuf generated message classes in the real world

The only problem is that a protobuf Message does not implement a simple interface - typically when you are receiving messages over a transport - you want to pass the messages on to handlers that know nothing about how they were encoded over the transport - indeed you might be handling the same message from different sources. OO would suggest that you're handlers would only require objects that allow access to he properties that they require to do their work. As the Protobuf Generated Message class has no means of attaching an interface one has to take one of two routes:

  1. Create a new Object from the Message (probably using a factory) that implements your interface; or
  2. Create a delegate that when you give it an object it extracts the relevant part.
The first doubles your number of objects created (one for the message and one for interface implementation. The second requires that extra complexity on the delegate and an extra call per property retrieved.

Proposal - decorating Generated Messages with Interfaces

My suggestion is to allow one to write an interface to encapsulate the properties you require from any message you will be processing and then decorate the Generated Message with that interface.

For instance, if we have a message in spotrate.proto:
message SpotRate {
 required uint64 timestamp = 1;
 required string currencyPair = 2;
 required double rate = 3;
 required string trader = 4;
 // ... and so on
Then if our message consumer was only interested in the currency pair andrate we would create an interface in
public interface ISpotRate {
 String getCurrencyPair();
 double getRate();

[HERE - show example new syntax and usage]

Cisco NSLU2 (Slug) death

I run a hacked Cisco NSLU2 ("Slug") NAS as a File, DNS, DHCP and HTTP Server here at home.

It is currently running Unslung (V2.3R63-uNSLUng-6.8-beta) from

I've had it since about 2006 and a little while back it failed showing no lights and it would not boot.

The power supply was ok with a healthy 5.3V but nothing I could do would coax it back to life.

Fearing that I would have to give up on it - I took it apart using instructions here: ??? Where are they ???

And found the following:

You can see that the two electrolytic capacitors on the right have blown. Their caps are slightly curved outwards. A quick trip to Maplins ( and a bit of soldering and they now look like this:

Re-assemble, apply power and all is well.

I'm just posting here in case anyone has a similar issue. It would be a shame to throw such a great little ARM computer just because it succumbed to a faulty batch of capacitors.

Sunday 8 April 2012

Velleman 8055 USB Experiment Interface Board

I have had this Interface board that I purchased from Maplin for a while and have finally got round to writing a Unix Library and Tool for accessing it via the Linux USB HID device.

Project is on Google Code:

Further details will appear on the project wiki but this picture is taken after running the following command to set the Digital Outputs to 7, Analog Output 1 to 128 and Analog Output 2  to 255. Multimeter is showing volts on Analog 1 (Roughly half of 5v). It is written in C.

[root@goflex src]# ./v8055 DO=7 AO1=128 AO2=255
Board: Vendor=4303, Product=21760, Version=0, Name=Velleman  USB K8055