A COMPARISON BETWEEN HYPERLEDGER FABRIC'S GO AND JAVA CHAINCODE API'S

20 november 2017

It’s hard to convince companies to make the switch to blockchains. Understandable, since why would they put their sensitive data on a worldwide public ledger? This is where private and permissioned blockchains come into play, the very pinnacle of which is called Hyperledger by the Linux Foundation. One of their branches is Hyperledger Fabric, which uses channels between peers of companies to execute chaincode between two or more parties. This supports our use case brilliantly.

Hyperledger Fabric currently supports a Java, Node.JS and a CLI SDK which can be used to interact with the private chain, with Python and Go SDK’s coming soon after the 1.0.0 release. Chaincode itself can be written in both Java and Go, which is awesome since this means we can have the full stack in Java and use Spring to write an application in very little time.

Or so we thought.

$ peer chaincode install -c {} -l java -n super-channel -p . -v 0
2017-11-16 07:22:22.809 CET [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-11-16 07:22:22.809 CET [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Java chaincode is work-in-progress and disabled

Turns out that since the 1.0.0 release, Java chaincode support was disabled for the time being. This means that we will be writing Go chaincode for the time being. No biggy, since Go is a very nice language which I recommend to anyone willing to take up a new language.

Since the key-value store writes byte arrays, using the Java API means that we’d need to either serialize stored objects or update byte arrays manually. Either way, this would mean a lot of boilerplate code. The Go API, on the other hand, has structs. This makes the whole process of retrieving or updating stored values trivial. Even in a general sense, in Go you will just have to write less code to do the same.

Another greatness is the ability to use unsigned numbers. Since it’s chaincode after all, one would want that it runs reasonably efficient without having half your data being useless. Sure, you can abuse Java’s 16 bit char, but that’s not a great practice, and uint16 makes me sleep better at night.

There’s a ton of features which make Go a great language, for the interested readers. Despite all this greatness, we are still actively looking forward towards the Java API!

Brecht Derwael – Blockchain Developer @ Trase