bitcoinj is written in Java for a variety of reasons, but I don't want it to be limited to only Java developers. In this post I'm going to discuss how I plan to enable the library to be used in conjunction with other languages. Specifically, I'll talk about ways it could be used from (Objective) C++, Python, Ruby and I'll briefly introduce Kotlin.
I'm also going to explain why I think Java or a similar language like Scala or Kotlin is a good choice for your next project, in case you haven't made up your mind about which tools to use yet.
Using bitcoinj from PythonPython has many fans and can be fun to prototype in. The original Python implementation cannot interop with Java code, but we can gain access via another way using
Jython. Jython is an implementation of Python (2.x) that is compatible with the original language/class libraries and provides an interactive interpreter that works just like regular Python's for exploration and learning. As long as you don't rely on any custom CPython extensions, you can just run your regular Python application out of the box, including UNIX style executable scripts.
Why would you do that? Primarily because you can import Java class libraries as you would Python class libraries (
from com.google.bitcoin.core import Wallet). You also get a better garbage collector and real multi-threading support.
I will try and post some examples of using Jython at some point soon. If anyone wants to beat me to it and contribute some demos, please do!
Using bitcoinj from RubyIn a similar vein to Jython, there is also
JRuby. Like Jython it runs Ruby on the JVM, with the same advantages - an excellent garbage collector, interop with Java code, real multi-threading support and so on. Like Jython the only thing it has issues with is modules that rely on C extension functions, but anything pure Ruby works.
I will try and post some examples of using JRuby with bitcoinj soon, but my knowledge of Ruby is pretty rusty so it may take longer. If anyone wants to contribute some demos, please do!
Using bitcoinj from C++ or Objective-C++There are several approaches to this, however they're all somewhat complicated and have a lot of caveats. I am currently experimenting with using j2c to automatically translate the code into C++11 so it can be compiled with a regular C++ compiler combined with the Boehm GC and the initial results are quite promising (you can translate almost all the OpenJDK class library). I previously prototyped using GCJ to do the same thing at a binary level and it worked, but it was hard to keep it up to date with the changing codebase.
J2C is an experimental Java to C++ transpiler. It generates neat and highly readable C++11 as can be seen from the included test cases. It works as an Eclipse plugin - you load your library into Eclipse, configure things correctly and click "Translate to C++". The code, including the java support libraries are then turned into C++ classes along with an automatically generated Makefile. You're then responsible for filling out the native method calls that would normally invoke the JVM (to do, e.g. file IO).
Once this is done you will be able to use bitcoinj classes from C++ very similar to how you would if it was written to be a normal C++ library.
Using bitcoinj with KotlinKotlin is a new, statically typed yet convenient language that can run either on the JVM or for a subset of programs, compile to JavaScript. It is developed by JetBrains, makers of the excellent IntelliJ IDE and can be summed up as a simpler version of Scala.
There's a web based compiler/editor
here so it's easy to play with and get a feel for the language.
I haven't used Kotlin yet, but I want to. It's my kind of language - familiar syntax, a strong focus on static type checking but makes good use of inference to avoid repetitive and boring code. Because it's developed by a commercial IDE company it also has a great IDE out of the box that supports inline refactoring and background, real time static analysis.
My opinions on how to pick a languageI'm sure we all just
loooove language flamewars, so I'll keep this brief. If you're about to write software that works with Bitcoin,
you are about to write software that handles money. For this reason your primary concern should be correctness above all else. Bugs that would be minor or inconsequential in other projects can open up serious security holes, create downtime for your product or even result in accidental destruction of money. At the very least even if your app crashes harmlessly or serves a 500 error, it will undermine peoples faith in the robustness of the whole Bitcoin ecosystem.
Environments that help you write bug free code tend to be ones where the computer can analyze your code as effectively as possible. That means languages with static rather than dynamic typing, excellent static analysis tools that have lots of bug-finding pattern matchers, and the ability to help the computer find even more bugs automatically with things like annotations. You also want a great support for unit testing, although most environments and languages have that nailed, these days.
It's for these reasons that I encourage you to carefully examine languages like Java, Kotlin or Scala. All of them hit all the above points. You will not accidentally lose/lock up peoples money due to a buffer overflow, type mismatch or null pointer dereferences.
Finally, the nature of what we're doing here with Bitcoin is that we have an ideological preference for peer to peer solutions. Whereas in many industries web apps or centralised services make the most sense, when handling money for a host of security and legal reasons I think it's preferable to just give users apps instead. That's where Bitcoin came from, it's what brought us together, and we should try and continue in that vein. Android is already based on Java, and modern versions of OpenJDK have radically improved the quality of desktop apps that can be built. These days they start fast, they can be turned into standalone bundles and JavaFX provides an OpenGL accelerated GUI toolkit that has a Mac-like animation API, nice themes, ability to embed webkit, styling with CSS and so on. Check it out the ensemble app here:
http://www.oracle.com/technetwork/java/javafx/samples/index.htmlJava has a poor reputation for desktop apps because of its history, so I was surprised to see how much they've been able to turn things around in recent years. If you previously wrote it off, I suggest you take another look. The big win of easy cross platform support is also still there.