C91（冬コミ）が近づいてきましたね。
今回のコミケにもTechBoosterが技術誌を発行するということで、わたしも「AndroidでJavaCPPを使用する」という記事で参加しています。
本当はAndroidにおけるJavaとC++の相互運用の最新事情をいろいろ調べてDroidKaigiでしゃべるつもりだったのですが、明らかに多くの人の興味を引くネタではなかったのでめでたく不採用となり、それなら今急いで調べなくてもいいかということで、今冬はとりあえずJavaCPPのみを調べてみることにしました。
C++相互運用は、わたしの中では「いつまで経っても解決しない.NETの課題」のとしてずっと関心をもっているネタのひとつで、当然ながら.NET以外の世界ではどう回っているのかも気にしています。
詳しくは本編を（買って）見ていただければと思うのですが*1、ここでも簡単にJavaCPPを紹介しておこうと思います。ちなみにわたしの寄稿部分は100% JavaとC++の話です。.NETは出てきません。あしからず。
JavaCPPは、C++ライブラリのヘッダから自動生成されるC++の中間ソースコードと（それをビルドして得られる）ネイティブglueライブラリを使用するタイプの、JavaとC++の自動的な相互運用を実現するプロジェクトです。
これ以外の「タイプ」でどのようなプロジェクトがあるかというと、プラットフォームの違いをglueライブラリで吸収するのではなく、プラットフォーム別のABIの違いを吸収するネイティブライブラリを活用して、ユーザーが純粋にJavaライブラリだけをビルドして配布することができる類のものです。一番有名なものはかつてSun Microsystemsで開発されていたJNAでしょう。また、5年前にBridJについて多分世界で2番目くらいに詳しい記事を書いたので*2、それを見てもらえればと思います。
JavaCPPはLLVMプロジェクトのclangを使用していて、それ自身の実装は割とlightweightに出来ています。BridJなど自前でC++ヘッダパーサーなどを書くのに比べてメンテナンスコストが低く、実際に現在でも継続している数少ないプロジェクトのひとつです（BridJはほぼ停止しています）。この「現在でも継続している」という特徴は割と無視できないもので、たとえばサンプルプロジェクトにもtensorflowのバインディングなどが存在しています。
JavaCPPのような、中間ライブラリ生成方式のフレームワークのデメリットは、結局プラットフォーム別にJNI呼び出し用のネイティブライブラリをバンドルしなければならず汎用性を損なう、という側面にあって、Androidの場合も例にもれず面倒なところです。そんなわけで、その辺をどうするか、みたいな話を主に書いています。
当日(12/29)はわたしも（たぶん午後あたりから）参加していると思うので、ぜひTechBoosterのブースに遊びで話しかけてやってください。西れ-63ab にあります。
