非IT企業に勤める中年サラリーマンのIT日記

非IT企業でしかもITとは全く関係ない部署にいる中年エンジニア。唯一の趣味がプログラミングという”自称”プログラマー。

Javaが反省すべき7つのこと

      2016/04/14

備忘録の最後に書いたとおり、不本意ながらJavaから離れることになったわけですが、これもすべてJavaの不甲斐なさだ!と半ば逆恨みしていますが、そんな勢いで恨み節7項目を書き出してみました。

1. ネイティブコンパイラではない
Java最大の欠点!もっともJava開発者は今でもこれが最大の強みと思っているようです。しかし起動の遅さが相変わらずネックになっていること、Java仮想マシンが必要であるためデバイスドライバ用の言語としても使えないといわれています。起動の遅さについての反論として、立ち上がってしまえば速度は申し分ないということも言われています。たしかに私もそう思います。しかし、比較的大規模ソフトの起動速度は正直絶望的。Eclipseが代表例でしょう。立ち上がるのを待つだけで眠くなります。しかも、その割りに「Write once, run anywhere」も怪しくなってきています。

↓例えばコレ。Eclipseをダウンロードする時にOSを選ばなければなりません。

OS固有になってしまっているという矛盾。だったら中間コードである必要があるのでしょうか?
起動の遅さから大規模ソフトウェアからは敬遠されていますし、かと言ってサクッと起動しないことから小さいソフトウェアにも向かず、中途半端な規模にしか向かないのではないかと思います。(そしてこのエリアの需要はあまりない) ネイティブコンパイラにしてくれたらどんなに良かったかと今更ながら思います。

2. ランチャーが残念
jarファイルにまとめればダブルクリックで立ち上がります。が、Windowsで一般的に認識されている起動ファイルはexeファイルなので、ちょっと馴染みがありません。例えばユーザーに配布するときに、jarファイルが実行ファイルだということを認識してくれるのでしょうか?JSmoothでランチャーを作ればexeファイルが作れますが、そんな手間を講じることなくWindows上だったらウソでもいいからexeファイルにしてほしかったですね。さらに、Linux上ではjarファイルが書庫ファイルと誤解され、ダブルクリックすると書庫マネージャが立ち上がるというトホホな結果に。手動で実行ファイルであることを設定しないとなりません。このあたり、「芸が荒い」と言わざるを得ません。

3. Libre Officeとの連携がない
個人的に一番のやってほしかったこと。C#はWindows上で容易にAccessと連携が取れます。特別なライブラリ(DLLファイル)を用意することなく簡単に接続できます。ところが、JavaがSunからOracle傘下になり、同時にOpenOffice(Openコミュと袂を分かち、LiberaOfficeと改称)も同様にOracleの傘下になり、互いに異母兄弟となったのにもかかわらず、一向に連携しようとする気配がありません。相乗効果はかなりのものと思うのですが・・・。接続するためのライブラリすら存在しません。これができればJavaに対する評価も大きく変わったはずなのに残念です。

4. 独自のプラットフォームをもつべきだった
ちょっとハードルが高いのですが、1項、2項の欠点を回避する1つの解決策として独自のプラットフォームを持つということがあります。Javaが中間コードである以上、ユーザーに仮想マシンをインストールしてもらわなければなりません。C#はMicroSoft製品なので当然ながらWindowsに.Net Frameworkが標準装備されていますが、一方でJavaは自分でダウンロードしてインストールしなければなりませんので、環境的にC#より不利な立場に立たされています。だから、LinuxベースでもいいからJavaは独自のプラットフォームを持つべきだったと思います。(あるいはSun時代であればSolarisベースでも良かったかもしれませんが、パソコン関係のリソースの豊富さを考えるとLinuxの方がベターでしょうか。) ここでJava仮想マシンを実装し、Javaソフトが最適に動作する環境になれば、このOSとともに人広く世界から評判を得られたかもしれません。

5. MicroSoftとケンカした
MicroSoftがJavaのライセンスをめぐって法廷で争うことになったことははっきりと記憶していると思います。プラットフォームに依存しないことがライセンス要件の1つだったのですが、MicroSoftはJavaにWindows特有の機能を備えてしまいました。これが元で法廷で争うことになり、結果、Microsoftが敗訴し、MicroSoftはSunに対して多額の違約金を支払う羽目になりました。一見、Sunの完全なる勝利に見えましたが、これが後のJavaの衰退の遠因にもなったと思っています。なぜなら、この一件以降、WindowsはJavaの同梱を止めてしまい、Net Frameworkという競合製品を作るきっかけになったのですから。今思えばSun側も少し歩み寄って双方が納得できる着地点を見つけるべきだったかもしれません。もっとも、これがボディーブローのような後からジワジワくるダメージになっていたということは、当時はだれも予想できていませんでしたが。

6. C#の台頭を許した

 前述の通り、結果的にMicroSoftはJavaと袂を分かち、独自の.Net Frameworkという実行環境をリリースしました。C#はJava同様、中間コードなのですが、起動までに時間がかかるということがありません。理由はよくわかりませんが、Windowsそのものが.Net Frameworkとの親和性をもたせようと設計されているのかもしれません。いずれにせよC#で製作したアプリの使用感がネイティブコンパイラで製作したアプリとほとんど変わらないところは正直驚きです。Javaに対してユーザーが何を不満に思っているか、MicroSoftはよく研究しているなと思います。この姿勢がJavaに足りなかったのではないかと思います。

7. サーバーサイドのシェアがいまひとつ
サーブレットやJSPは個人的には他の言語よりすぐれていると思います。正直PHPやParlでは仕様が曖昧すぎてあまり好きではありません。個人的にはこの分野でJavaを使いたいのですが、残念ながらシェアがいまひとつです。少なくとも、日本の有名どころのレンタルサーバーでJavaをサポートしているところはかなり少ないと思います。(あっても月額が高価) 例えば「ロリポップ」や「さくらインターネット」あたりでサポートしてほしいところです。サーバーサイドでシェアが低い理由は正直わかりませんが、サーバー側でコンパイルする負荷があるからなのでしょうか。

スポンサーリンク

 - 技術系コラム