2012年07月31日(火)

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

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

筆者は本格的なJavaのコーディングは行っておりませんが、C/C++に関しては２０年弱ほど職業プログラマーとしてのコーディング歴があり（同じコードを使いまわして20年じゃないよ）、大規模レベルのAndoroidアプリの開発において初めてJava開発環境に関わりました。

３． packageという、C++のnamespaceをむしろダメにしたような機能が付いてくる（＜指摘内容が言語仕様レベルかは不明）

http://ja.wikipedia.org/wiki/%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8_(Java)

こいつは自分の体験談のみなもんで確証が無くて申し訳ないのだが、Ecripseからひとつのパッケージをコンパイルして、それをコマンドラインからJARに固めて外部から呼び出しを行った場合での不具合が余りにも酷いので挙げさせてもらった。
（前の2つに較べたら大分弱い）

まずプログラムを行う際に自分が作成する成果物を、package というC++のnamespaceのような名前空間のようなものに定義する事ができる（他社、他のプロジェクトと衝突しないために”すべき”である）。
これは別にC++でもnamespaceで（更に#include を組み合わせる事により更に強力に）実現できるもの。
そしてこのpackageはソースファイルの先頭部分（＜クラス等定義の前）に”テキストにて”記述する。
Ecripseのような統合環境を使用していても、ソース内に使用するpackageは記載する事ができるし、この記述が自動で削除されたり上書きされるような事も無い。

が、実際に使ってみた場合に（＜どこかやり方が間違ってる可能性はあるんだが）以下のような不具合が発生する。

パッケージ名は実際にはJARに格納される際のパス（ディレクトリ名）と完全に一致している必要があるらしく、このパッケージ名とファイルが存在するパスの不一致により、実行時に”呼び出しているクラス名が存在しない”という例外を吐かれる。
更にこの例外を吐かれている要因を突き止める事がほぼ不可能（指定されているパスに”ファイルが見つからない”というエラーしか出さない）。

言い替えてみると、packageはnamespaceのふりをしている癖に、実際には#includeのパスを兼ねていて勝手にそれ（ファイルの存在位置）を強制する、という感じだろうか。

まあ特殊な環境でやっているものだから必ずこういうものだ、っていうのかどうかは不明でアレなんだけれど。

namespaceの名前自体を気に入らないから変えてみますた、って思ってやってみたら#includeの書き換えを全部行うどころか、ファイルが置いてある場所のディレクトリ名変更や移動までやる必要がある、っていう代物の状態だった。＜当然SVNのフォルダとか名前変更とかまでやらされる羽目になるオチまで着いてくる
（これを行う為にどうもEcripseには”リファクタリング：名前の変更”という機能がある様子）

統合環境（IDE）前提の言語なのは理解できるが、この中途半端な対応状態は相当のレベルで酷い。
あとから作成されている言語仕様や環境なのに

「何故この機能がこうなっているのか」を説明できない要素がある

っていうのは正直結構怪しいと思わされる。
少なくともこのエラーメッセージから見た目上の仕様から何から全て、この理由でこうなっていますという明確な裏づけが一切感じられない。
敢えて挙げるとしたら、ZIPアーカイバに全てを委ね過ぎてしまってるからじゃね？ っていう邪推はしてしまうけどね。＜そんなのは当然裏づけとして認められません

　
まあ正直「言語のダメな所」の1点として挙げるには若干弱い要素だったりはするんだけれどね。
実質的ネタ切れですハイ。
最初にヒデヲに言われてじゃあ「ダメな３大ポイント」にしよう、それぐらいネタあるだろう、ってやってみたんだけれど思ったよりも最初の２つが大きな問題過ぎて、残りは結構瑣末なものかなって感じだった。
デバッガーの話とかしようかなと思ったけれど、実際に使ってみてはいないので書くまでに調べる内容が多くなり過ぎるのでコイツもネタとしては没。

てな感じでオマケじゃないけれど、３大ポイントに付け加えた若干言いがかり的な部分をもう１回追加でやります。＜３．１、３．２でやろうと思ったけれどやはり長くなったもので別項目扱いにする。

という訳でまだ二週はこのネタは継続で続けられそうですハイ。