Roadmap for adding new language bindings

When considering new language bindings, there are certain points to think about. First, you should find out, if you are about to implement completely new language bindings that are not yet supported with Thrift, or if you just want to add support for a specific “flavour” of an already implemented language.

Q: The language exists, but it lacks support for $feature or $version! What should I do?

In that case, it is recommended to add the new feature as an option to the existing language. For a good model on how to do this take look at the js/nodejs implementations, or the various options that already exist for Python. thrift --help gives a great start. Depending on the amount of changes necessary, you will still find the rest of the document useful.

General workflow


The good news is, although there is some work required, the process is not as hard as it looks. First, make sure you have a fully functional build environment and are able to build the compiler from source. Read the How to Contribute section to understand, how the general contribution process works.

Next, search Jira and maybe the mailing list archives. If you do not find anything similar, create a new ticket, shortly describing what you are planning. If you are not quite sure, ask on the developer’s mailing list.

Now fork the Apache Thrift code base on GitHub. Although we accept patch files, especially for comparingly long-living feature branches (such as adding a new language) a GitHub branch is much easier to handle.

Implement a minimal feature set

The minimal feature set

The minimum required feature set should cover at least:

These are not strictly required in the first run, but are commonly used. Depending on the language, some things may be easier to implement than others. Alternatively, consider adding the features listed below later as additional contributions instead of trying to press them into the initial contribution. If in doubt, focus on quality rather than quantity.

Final things


Note that the 4 implementation steps are not really a linear process, it is more kind of an iteration. Even if the code that comes out of the generator finally is compileable and does not spit out any warnings and seems to run fine, you still will run into problems as you move on with implementing library and tests. This is fully normal and expected.

It is a good idea to post your work early on the mailing lists, and to create the JIRA ticket early - that’s why this particular point is on top of the list. This serves not only the purpose of announcing the work you are about to do, it is also a good starting point for other people who might be just looking for exactly that stuff. You will be able not only to get valuable early feedback, but probably also be able to raise some support with implementation and/or testing. Having someone else looking over your code (or reviewing each other) is generally a good thing, especially with regard to the overall quality of the contribution you are about to do.

Happy coding!