Introducing BitcoinKit.framework



Summary:

There are different options for implementing a native client for Bitcoin, including embedding the Java Virtual Machine (JVM) or transpiling bitcoinj to C++. While it is possible to reduce the size of the JVM to a few megabytes, it may not be necessary for desktop apps since bandwidth has improved. Portability to Android is already possible because it is Java-based, but iOS is a challenge due to Apple's restrictions on wallet apps in its App Store.One option is to rewrite bitcoinj in C++, but this is unnecessary given the existence of j2c, which does an excellent job of transpiling Java to C++. Another option is to embed the JVM and link it with the native app using a thin interface that calls into the Java code when user-visible events occur. This approach is less ambitious than transpilation but requires writing some Java code. The auto-translator javacpp can help with this.Rewriting bitcoinj in C++ or transpiling it to C++ requires a significant amount of work but could result in a stable, portable, and extendable piece of code. Embedding the JVM requires less work and can achieve good results quickly. The JVM can be bundled with the app and stripped down if necessary to reduce the download size. The primary problem with the Oracle JVM is the lack of retina support for Swing, but this doesn't matter if the app uses a Cocoa UI. Retina support for JavaFX2, the current-gen GUI toolkit, is available in Java 8, indicating active development.SPV mode is essential for improving synchronization time, and the only SPV mode implementation known so far is bitcoinj. The author of bitcoinj is experimenting with transpiling it to C++ to make it usable from Objective-C++.Overall, both options have their pros and cons, but embedding the JVM is a more straightforward path that can achieve results quickly, while transpiling bitcoinj to C++ is more ambitious but could result in better stability, portability, and extendibility.


Updated on: 2023-06-06T20:03:43.803141+00:00