はじめに
私はこれまでのエンジニア歴で継続的にJavaを使い続けていますが、以前と比較すると使い勝手の面で格段に良くなっていると実感しています。
また、JJUG、JSUGなどで講演を聞いたりしたりする中で、個人的に最近のJava界隈は非常に進歩的で良い感じだと感じています。
そんな中、「Javaは人口が多いだけで特別に採用するメリットが無い」「Javaはレガシーで生産性が低い」というツイートを見かけたので、その反論を込めて私の考えを書き連ねたいと思います。
なお、以下で述べる内容には、Javaが良いというよりは、特定のフレームワークが良いだけ、というものもありますが、あくまでJava「界隈」について述べているのであしからず 。
最近のJavaの良いと思う点
- 言語仕様、標準ライブラリの改善
- プロジェクトの立ち上がりの早さ
- 型安全性の活用
- マイクロサービスアーキテクチャへの対応
- パフォーマンスの改善
1. 言語仕様、標準ライブラリの改善
もう大分前になりましたが、ラムダ式やStream APIが導入されてから格段にプログラミング効率および正確性が上がったと感じています。
また、標準ライブラリも、かつての極端なミニマリストから、「開発者が頻繁に使うものは標準ライブラリに取り込む」という現実に対して前向きな考えにシフトしていると感じています。
さらに、JDK9以降リリースサイクルも見直しされ、より言語進化のスピードが上がることが期待できます。（JDKバージョンをどうするかという問題が発生しますが、それは一旦置いておきます）
2. プロジェクトの立ち上がりの早さ
Spring Frameworkにおいて、Spring Initializer、もしくはEclipseプラグインで瞬時にWebアプリを作成することができます。
内蔵のサーバを使えば特に何も用意せずにmain関数からサーバ起動することができます。
参考：SPRING INITIALIZRを使ったSpringBootプロジェクトのひな壇の作り方
関連ライブラリも非常に数多く、しかもpom.xmlに依存を書き込むだけで使える手軽さがあります。
3. 型安全性
静的な型付けには賛否あると思いますが、最近のJava界隈は良い面を引き出していると思っています。
Stream API
例えばStream APIは静的な型付けと相性が良く、結構な長さのコードを一気に書き上げてもコンパイルが通ればほぼ意図したとおりに動き、使いこなせばとても効率よくコーディングできます。
Spring Boot
Spring Frameworkは、かつてのXMLベースの設定から、アノテーションによる型安全な設定が行えるようになりました。これによりBean定義の行いやすさ、メンテナンス性が飛躍的に高まったと感じています。
参考：Spring BootのAutoConfigureの仕組みを理解する
なお、このようなBean定義するメリットは色々ありますが、例えばテスト自動化が行いやすくなり、ひいては言語、フレームワークのバージョンアップ作業コストを抑えることができます。
DBFlute
私が最も好きなフレームワークであり、DB変更に強いDBFluteという非常に優れたO/Rマッパーがあります。スキーマのメタデータを読み取りJavaソースコードを自動生成することで型安全性を保っています。
これを使うと、可読性の高い簡潔なJavaコードでデータアクセスがさくさく実装でき、しかもコンパイルが通ればほぼ意図通りのSQLが実行されるという点で、使いこなせば非常に高い生産性を期待できます。
4.マイクロサービスアーキテクチャへの対応
マイクロサービスアーキテクチャに対して、Spring Cloudという名前で様々なライブラリが提供されています。
私自身は実務で触れたことがないのですが、Springを活用したマイクロサービスへの取り組みは度々講演で題材にされています。
参考：ぱぱっと理解するSpring Cloudの基本
参考：【Spring Fest 2018 レポート】決済システムの内製化への旅 – SpringとPCFで作るクラウドネイティブなシステム開発
また、micrometerというメトリクス計測用データを蓄積・提供するライブラリがあり、JSUG 2018の幾つかの講演で取り上げられました。
これも、Spring Boot2系になってからはpom.xmlに依存を記述するだけで、起動時にバックグラウンドで動くようになり、また計測対象のカスタマイズも容易らしいです。
参考：Spring Boot で micrometer を使ってメトリクスを計測・送信する
5. パフォーマンスへの考慮
最近のSpring Frameworkでは、パフォーマンスがシビアに要求される環境へ適合するための取り組みが活発に行われているように感じています。
WebFlux
Spring5の目玉機能であるWebFluxを使えば、少ないスレッドで多量のリクエストを捌くことができ、リソースの有効活用ができます。
参考：Spring WebFlux の概要を理解する
ただし、今現在だとJDBCがReactive対応していないため、実務で使うのにかなりの制約が残っていますが、これもSpringが取り組んでいるみたいです（そこまでやるか、という感じです）。
参考：SpringOneでR2DBCが発表された
ネイティブ化
GraalVMを使うと、Javaアプリケーションをネイティブ化できるらしいです。
JSUG 2018の基調講演におけるデモで、GraalVMによりSpringアプリケーションをネイティブ化して、通常1秒以上かかるものがミリ秒で起動可能になるのを目にしました。現在はかなり限られた状況でしか適用できないようですが、いずれ全面サポートを目指す、と聞こえました（英語の講演だったので自信ありませんが）。
参考：SPRING FEST 2018
おわりに
あまり考えがまとまっていない駄文を連ねてみます。
Javaの進歩の遅さ、強固な「思想」について
Javaは、時代による遷移はあれど「思想」を強く持った言語だと思います。
また、Javaフレームワークも同様に強固な思想を持つものが多いように感じます。
おそらく、そこで好き嫌いが分かれたり、ときには争いに発展したりするのではないでしょうか。
「Java API 訴訟の件で私が Google よりも Oracle の肩を持つ理由」という記事に対して、Oracleに対して特段好き嫌いの感情を持ち合わせていませんが、内容には同意しています。
「Javaはコミュニティの力で再び偉大になれるのか」にあるように、全体のバランスを崩さないよう、慎重かつオープンに議論を重ねて仕様を決定するプロセスは、見る人によっては遅々として進歩がないように見えるかもしれません。しかし、私はこのような慎重さで全体整合性を保つことは大いに意味があると考えています（javaの仕様に全く不満がないわけではありませんが）。
言語にしろフレームワークにしろ、うまく使いこなすには「思想」を理解することが大事だと考えています。逆に、思想が読み取れなかったり、中途半端な妥協が垣間見えるものは使い方に戸惑ったり、好きになれなかったりします。
静的な型付けについて
私自身はJavaScriptも比較的好んで書くため、静的型付けのない言語の良さもよくわかっているつもりです。JavaScriptからJavaに移った場合、記述量の多さに苛立つこともあります。
そのため、Javaの強固な静的型付けシステムに対する反発を覚える気持ちはわかります。
しかし、上で述べたように使い方次第によっては強力な武器にもなると感じています。
ソフトウェアの規模が大きくなった場合に静的な型付けがないとメンテナンスが厳しいなと想像しています。
冷静にメリット・デメリットの議論を
言語仕様的には古くて欠陥も残るJavaですが、それでも必死で後方互換性を保ちつつ全体のバランスを保ちつつ進化を模索していると思っています。
それに対して、「Javaは時代遅れで生産性が低い」とディスる人は、一体どんな尖った技術を使っているんだろうと思ってしまいます。
例えば、マイクロサービスアーキテクチャに対して、Springのようなアプローチを取っているようなフレームワークがあるでしょうか（といっても、他のフレームワークは詳しくないので何とも言えませんが）。
どの言語、フレームワークを採用するか、究極的には好き嫌いに帰着すると思いますが、最近の事情を知った上で冷静にメリット・デメリットを議論できれば良いかなと思います。
最後までお付き合い頂きありがとうございました。
2018/11/11 追記
記事内に一部、特定言語をディスる記載がありましたが、予想以上に閲覧数が多く、本題からの逸脱が激しいため削除しました。（確認したい方はコメント欄を見ていただければと思います。）。
炎上させる意図は全く持っていないため、今後特定言語への批判は避けたいと思います。
2018/11/17 追記
JDKに関する意見や不安などが結構見受けられたため、自分なりの考察を書いてみました。的外れかもしれませんが、良ければ参考にしてください。
Javaの現状整理と今後についての考察