Java の最大の利点は本当にクロスプラットフォームであることでしょうか?

以下の説明はPCおよびモバイル端末のみを対象としています。

Java の最大の利点は本当にクロスプラットフォームであることでしょうか?以前はそうでしたが、今はそうではありません。

クロスプラットフォーム要件があるのはクライアント アプリケーションのみであり、サーバーではありません。たとえば、デスクトップ アプリケーションの場合、顧客は Windows ユーザーまたは Linux ユーザーである可能性があり、各プラットフォームに適応するためにこれ以上投資したくない場合は、Java のいわゆる「一度書けばどこでも実行できる」機能が非常に優れたものになります。しかし、今日ではソフトウェアの世界全体が B/S アプリケーション (組み込みを除く) に傾いています。たとえクライアントがクロスプラットフォームであっても、QT などのサードパーティ フレームワークは Swing Java よりもはるかに強力です。デスクトップアプリケーションの分野では、これは議論の余地のない事実であり、Java が誇りに思っていたアプレットはとうの昔に姿を消しました。クライアントサイド Java に優れた点があるとすれば、それは Android だけです。 Android は当初、異なるハードウェア デバイス間の違いを保護するために JVM に依存し、大きな成功を収めましたが、現在、Android L の ART モードの登場によりこの状況が覆されようとしており、Google も独自の Go 言語を使用したいと考えているかもしれません。 Android プラットフォームの最初の言語としての Java。したがって、クライアント側では、Java はほぼ完全に敗北しています。

サーバー側アプリケーションはクロスプラットフォームである必要はありません。 Web サーバーを構築するときに、現在 Linux を使用し、来月には Windows に切り替える企業はないと思います。 Debian から Fedora など、Linux ディストリビューションを変更するだけの場合、基本的に Linux カーネルは変更されないため、C++ のような純粋にコンパイルされた言語では問題ありません。ゲームサーバーを構築する場合、ほとんどの人が Win プラットフォームではなく Linux を選択すると思います。 Java のクロスプラットフォームの利点は、実際には大幅に弱まっています。通常の状況では、Java がクロスプラットフォームであることを認識することはほとんど不可能であると言えます。 3 つの主要な商用 JVM の 1 つである JRockets はコンパイラ専用の JVM です。つまり、アプリケーションの起動時にすべてのバイトコードがローカル マシン コードにコンパイルされます。これにより、実際にはクロスプラットフォームが大幅に放棄され、パフォーマンスが追求されます。

今日、Java の最大の利点は、その大規模で完全なエコシステムです。 プログラミング言語が普及できるかどうかは、主にそのエコシステムによって決まります。 Java エコシステムの完成度は主に次の側面に反映されています:

Java には世界で最も多くのプログラマーがいます。農家と言っても構わないのですが、その数によっては企業が人材を採用する際にJavaプログラマーを採用しやすくなるというのが一番の効果です。想像してみてください。ソフトウェアのセットを作成したいと考えていて、C++、Scala、Ruby などの言語で実装する必要がある優れた技術ソリューションがあるにもかかわらず、十分な人材を採用できない場合、その計画は最も効果的です。おそらく無駄になるでしょう。現時点では、アプリケーション Java でもそれが可能であり、十分な人材を簡単に採用できるため、Java を選択する可能性が高くなります。

Java には多数のサードパーティ ライブラリがあります。 HTML を解析したい場合は、おそらく C/C++ などの言語で独自の解析アルゴリズム ライブラリを作成する必要がありますが、Java の場合は、Github で JSoup を簡単に見つけて、Maven を使用して依存関係をインポートし、 HTML は数分で完成します。このため、Java を風刺する言葉があります。「私たちはコードを生成しているわけではありません。私たちは単なる Github 移植者です。」この文は文字通り意味はありますが、大きな価値のあるソフトウェアの生産効率の向上を無視しています。ソフトウェア開発の場合、企業のコストは実際には「資本金」だけです。開発期間が 1 か月短縮されるたびに、数十万、数千万の研究開発費を節約できます。

Java には強力な IDE があります。 Eclipse は、プラグインを通じてほぼすべての開発ニーズに対応できます。少し遅いですが、JVM チューニングによってプログラムのスムーズさを向上させることができます。デフォルトの JVM パラメータは決して使用しないでください。しかし、IntelliJ Idea は Eclipse を完全に上回り、Idea のインテリジェンスは Win プラットフォームの VS とほぼ同等です。私は Vim なしでは生きていけないタイプの人間ですが、両方の IDE に Vim プラグインがあり、私を楽しく生きさせてくれます。

Java には多くのキラー アプリケーションがあります。 言うまでもなく、Spring、Struts、Hibernate、Hadoop、Tomcat、JBoss などです。

Java には構文機能がほとんどありません。はい、それもプラスです。 C++ は C に比べて多くの機能を追加します。学習が難しいだけでなく、使用時のコードの可読性も低下します。実際、時間と労力の無駄です。今日の世界では、プログラミング言語の要件はシンプルな構文と読みやすいコードであり、パフォーマンスが次善の策であるため、Python や Ruby などのプログラミング言語が誕生しました。 Java 構文が肥大化していると多くの人が批判しており、私もそれを認めますが、実際のところ、プログラミング言語は構文が肥大化したために廃止されたわけではなく、その生死を決めるのはエコシステムです。批評家向けに、Zhihu の言葉を引用します。「動的型はしばらくの間は優れていますが、コードのリファクタリングは火葬場です。」

Java のパフォーマンスはすでに十分に高いです。 Sun/Oracle の HotSpot JVM の組み込み JIT コンパイラは、実行時にバイトコードを最適化するために多大な努力を払ってきました。サーバー アプリケーションの起動後、JVM は十分に「ウォームアップ」され、適切な起動パラメータが与えられます。パフォーマンスに非常に敏感なシステム アプリケーションでなければ、Java は十分に高速です。これを視覚化する簡単で実行可能な方法があります。+XX:PrintCompilation を JVM 起動パラメータに追加して、JIT コンパイラのビジー度を確認します。今日の世界では、パフォーマンスが許容できる場合、開発効率が最優先され、これが Python などの動的スクリプト言語が人気の主な理由でもあります

。