2012年07月17日(火)

Java言語のダメな所３大ポイント （１）（Programingの話）

※ あくまでも個人的な感想です。

筆者は本格的なJavaのコーディングは行っておりませんが、C/C++に関しては２０年弱ほど職業プログラマーとしてのコーディング歴があり（同じコードを使いまわして20年じゃないよ）、大規模レベルのAndoroidアプリの開発において初めてJava開発環境に関わりました。
　
１．JavaVM上で動かすコードがコンパイルされたアセンブラコードではなく、ソースコードそのままである点

そもそもの設計段階に文句をつけている訳だが、サーバー上で完結するようなシステム／アプリならばいざ知らず、クライアントへ実行ファイルを配布して実行するタイプだと本当に致命的。
アプリを有償ダウンロードして終わりというレベルの商売ならば、かろうじてアリだろう。

基本的に配布されるアプリ（パッケージ）にソースコードがほぼそのままの状態で含まれているのがJavaアプリケーション。
jar という形式で配布や実行ファイルが作成されるのだが、この中身は単なるZIPファイル。
更にその中には、クラス名から構成から変数名まで、ソースコードがほぼそのまま残されている。＜テキスト形式ではさすがに無いが

これらを解析するツールがそもそも存在してる為、配布されているJavaアプリは全て容易に解析が可能となっている。

この容易さという部分が重要。

C/C++及びアセンブラで書かれたプロジェクトは最終的に実行ファイルの段階で、プラットフォームのアセンブラへと変換される。
が、これを逆アセンブル、逆コンパイルというリバースエンジニアリング技術により解析を行い、クラック行為等を行う事は実質上可能である。
が、この行為が可能な能力というものは非常に限られた高度な能力で、全プログラマーを能力順に並べた場合、これができる人間は確実に上位5%以内に入る。＜これはかなり多めに見積もった数字である

これをJavaに関していうと、最低限の言語仕様が理解できるレベルであればツール等が充実している事、プラットフォーム毎のバイナリコードで無いのでJavaのコードさえ読めれば解析が可能である事により、リバースエンジニアリングに必要な技術力（要は参入障壁）が劇的に低いと言える。

あえてC/C++の 5% に対して数値化するのであれば、20～30％という数を挙げさせて頂く。

この構造上の欠陥点に早くから気づいていた人たちは多く、Javaに関しては”難読化”（Obfascate）というキーワードが示す対策が取られてはいる。
Javaの標準開発環境であるEcripseにおいてはこの難読化ツールが標準で組み込まれており、Andoroidアプリで言えばアプリ定義用のXMLファイルにて定義を行えば自動的に難読化は行われる。

のだが、この難読化というのは単にクラス名、変数名、関数名を分かりづらい記号に置換するだけのものであり、ソースがそのまま内包されている事にはなんら変わりはない。
リバースエンジニアリングへの障壁が若干上がっているだけで、本質的に本気でやる気になった場合はC/C++のそれよりも遥かに容易に行う事が可能である。

　
と非常に前置きが長くなって申し訳無いのだが、要するにアプリケーション開発者がアプリ配布後のクラック等の行為に対して、必要以上に対策を行う必要があるという見えないコストを孕んでいるのだ。

しかもこのコスト、プロジェクト終盤どころかリリース後に発覚したりするので始末に負えない。

サービスやアプリがようやく完成しました！ → リリース → 大人気 → クラック等される →
対策が必要 → アプリやサービスの再設計レベルの修正が必要

という一連の流れはちょっと大げさに書いたりはしたけれども、まあ全く考えられない話では無いかな、と。

そもそもJava的なVM上でソースがそのまま動くという思想はウィルス的なものを排除もしくは早期に発見する目的で考案された仕様と推察するのだが、それはそっくりそのままリリース＝ソース公開というアプリ、サービスを販売する視点からすると問題がありすぎる、ちょっと踏み込んで表現すると危険な思想の部類に入るものかなあ、と。

　
※ 冒頭にも少し書いたけれど、サーバー上で大メモリ＆高速CPUハードウェア構成の前提で更に外に公開される事が無いアプリ／サービスを作成する分に関しては、この件は全く問題になりません。

　
以下独り言。
最初の1項目でもうこんな超大作になってしまった…。ちゃんと構成を考えて書ければいいのだがそれだと今の倍は時間かかるし。
これをどうやって今北産業にまとめるというのか。
（基本的に超複雑な事を説明しているので、簡単に説明しようとする方が間違いではあるんだが）