こんにちは NSS の江口と申します。
NSSでは入社の際に新人研修としてC言語とJavaを学習します。
その後現場に出てからもずっとJavaを利用してまいりました。
そのまま 15 年、特に疑問を抱くことなく過ごしてきたのですが、様々な言語が登場しては下火になっている中、根強い人気を誇っています。
私自身Javaは結構好きでこれからも発展してほしいので、改めてなぜこれほどまでに Java が強いのかを考察してまいりたいと思います。

理由① シェア

IPAが発表している資料によると、開発プロダクトの 42.4% が Java で動作しているそうです。
ソフトウェア開発分析データ集 2022
これは対象プロダクトが金融関連が多いこともその一因だと思います。私は金融関連のプロダクトに携わることが多いのですが、
Javaを実行環境に選択しているプロダクトは本当に多いです。
既にシェアが高いし、大きな不満もない。なので次もJavaになる。ということなのかなと思います。
私個人としてはクライアント側に少し弱みがあると思いますが、サーバ側ではこれといった不満がないです。
実際クライアント側は AWT/Swing/JavaFX といずれも下火になっているので、Javaはサーバ側の実行環境として発展していくのだろうなと思います。

理由② Write once, run anywhere

今のご時世これをサポートする言語も多いので、ありがたみが半減しているかと思うのですが、十数年前の常識ですと、CやC++では実行環境に応じたソースの書き換えが必要でした。
例えば以下は、Linuxにてソケットクライアントでメッセージを送信するプログラムとなります。

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <cstring>

int main() {

    // ソケット生成
    int sockfd = socket(AF_INET, SOCK_STREAM, 0);

    // 送信先アドレス・ポート番号設定
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_port = htons(1234);
    addr.sin_addr.s_addr = inet_addr("127.0.0.1");

    // サーバ接続
    connect(sockfd, (struct sockaddr *)&addr, sizeof(struct sockaddr_in));

    // データ送信
    char send_str[] = "Hello.";
    send(sockfd, send_str, strlen(send_str), 0);

    // シャットダウン
    shutdown(sockfd, SHUT_RDWR);

    // ソケットクローズ
    close(sockfd);

    return 0;
}

ではこれと同等のものをWindowsで実装しようと思うと、

呼び出すライブラリはsys/socket.hではなくwinsock2.hをincludeする
closeではなくclosesocketを呼び出す

などといった違いがありますが、Javaであればこの差分はJavaVMが吸収してくれるので、コーディング自体は同一でよくなります。
レジストリや名前付きパイプなどは、どうしてもOS毎の機能的な差分を吸収しきれないことが多いですが、サーバであればほぼ網羅できるのではないかと思います。

理由③ オブジェクト指向

この考え方の導入により、機能を抽象化することができるようになり、協業がしやすくなったという側面があると思います。
これは後述するガベージコレクションの登場により、オブジェクトのライフサイクルの管理をする必要がなくなったということがよりオブジェクト指向を後押ししたと考えています。
登場人物としてのオブジェクトが登場し、それらがコラボレーションしながらシステムを構成していくわけなので、システムの説明もしやすくなりました。

理由④ ガベージコレクション

参照されていないメモリを勝手に解放してくれる仕組みです。先に述べたように設計でもプログラムでも面倒な非機能要件から解放されるのは大きいです。

通常の株式取引のシステムであれば、

トレーダー
銘柄
発注
約定

などに該当するオブジェクトを作成し、それらを組み合わせて設計します。
ガベージコレクションがない場合、

トレーダーが発注するんだけど、この発注っていうものの生存期間はhogefugaで。。。

と考える必要があり、設計で盛り上がっているのになかなか水を差す制約ですよね。
何度かC言語でプロダクトを作成するプロジェクトに従事しましたが、メモリ管理には本当に気を付けて設計しますし、ヒートランなども念入りに実行することが多いです。
また、メモリリークについては自分たちが作成するソースコードはもちろんなのですが、利用しているライブラリ内でメモリリークしているというケースもあり、そういった場合はどうしようもなくなります。
C言語ではサードパーティ製のライブラリを導入する際には事前にヒートランなどを実行したり、すごく神経質になっていたのですが、
Javaになってからは本当に不要ならJavaVMが勝手に片づけてくれるので、以前ほどライブラリの選定に神経質にならずに済むようになりました。近年はダウンロード数、スターの数、更新の頻度が相当低くない限り、躊躇することってあんまりないですよね。

理由⑤ コンパイル言語

これは当たり前だとも思えるのですが、いわゆるコンパイル言語なので、コンパイルしないと実行可能になりません。
実行前に文法的な不備は検出できるというのが良いです。いわゆるスクリプト言語と比較するとずっと動作する必要のあるサーバプログラムを想定した際にJavaはやはり安心感があります。
AWS LambdaなどはJavaの場合はクラスロードの時間などもあり、pythonの方が適していると思いますが、常駐するアプリはJavaがかなり強いと思います。

まとめ

Javaの良いところをここまで述べてきました。今後もJavaが発展していってくれることを願います。次はJavaのJITコンパイラについて投稿したいと思います。