Java（まだ）選択したクロスプラットフォーム言語ですか？
私がJavaを90年代に使い始めたとき、それはすべて「1回書き込み、どこでも実行します！」から1日目でした。 。それはおそらく当時は真実であり、私も合唱団の一員でした。
マルチプラットフォームランタイムを使用する他のすべての言語（python、flash、Perl、html、php ...）を考慮すると、これについてどう考えるかはわかりません。しかし、私はまだJavaを使用する必要があると言っている多くの議論を見続けています。
それで、それは今日でも本当ですか？Javaはまだマルチプラットフォーム開発に最適な言語ですか？
- クロスプラットフォームの側面に焦点を当てて具体的に説明してください。
- 一般的な言語機能の比較は求めていません。
更新：これまでのところ素晴らしい回答です！ほとんどの回答は、JavaまたはWebを支持しているようです。スクリプト群衆からの入力はありますか？
pythonなどのスクリプトスタイル言語もクロスプラットフォーム開発を容易にします。ここで、Python（または他のそのような言語））が好きかどうかはあなた次第です。ここでその議論を始める必要はありません。
pythonを使用すると、移植可能なコードを作成できます。実際のpython言語自体は移植可能に実行されますが、また、pythonは、プラットフォーム固有のサービスへのアクセスを自由に提供します。
Javaそこに利点はありますか？どちらの場合でも、移植可能なコードを同じくらい簡単に書くことができると思います。つまり、コードを書くことができ、通常は異なるプラットフォームで動作します。しかし、コードを書くだけで、どこでも機能することを前提にしています。pythonプロジェクトでWindows、Linux、Mac用のバージョンを作成しましたが、クロスプラットフォームの問題はほとんど発生しませんでした。（私が覚えている唯一のことは、pygameを使用していたライブラリのバグが原因で、Linuxで描画の問題が発生していました。これは、使用したpygameのバージョンをアップグレードすることで修正されました）
もう1つの問題は展開です。コードを実行するスタンドアロンプログラムを配布する場合は、プラットフォームごとに異なるバージョンを作成する必要があります。 Javaの場合、1つのバージョンを配布し、ユーザーがJavaをインストールするか、インストールできると想定します。この場合、Java =おそらく導入部門のシンプルさで勝ちます。
結局のところ、どの言語で作業するのが好きか、どのような展開を実行する必要があるかが問題だと思います。
Javaはtheまたはしか実行できない場合がありますクロスプラットフォームツール、いくつかの長所があります。
- 非常に高速です。
- 非常に堅牢です。
- それは非常に移植性があります（たとえば、Windows 95で10年前にコンパイルされたバイトコードは、今日のOS Xで正常に動作します）。
そしていくつかの弱点：
- コアGUIライブラリ（Swing ...）は、その古さを示しています（サードパーティの追加がここで役立ちます）。
- 言語自体はそれほど冗長ではない可能性があります（たとえば、チェックされた例外...）。
- 起動時間はより速くなる可能性があります（ただし、常に改善されています）。
Java theplatform）について具体的に説明すると、もう1つポイントがあります。
- JVMで実行される かなりの数 言語があり、Javaと相互運用します。
それは当時と同じように今日も当てはまります。 Javaは1回の書き込みで、どこでもテストおよびデバッグできます。確かに、完全に新しいポートよりも作業量ははるかに少なくなりますが、通常、当初の誇大広告が信じていたよりも作業量は多くなります。
私たちの製品にはJavaサーバーがあり、WindowsまたはLinuxのいずれかで実行されますが、OS固有の問題があり、必要に応じてLinuxサーバーとWindowsサーバーの両方をサポート/テストできることを確認します。 Java UIはサーバーよりも多くの問題を抱える傾向があります（ただし、多くは表面的なものであるため、アプリケーションによっては無視できる可能性があります）。
厳密には私にとって言語ではありませんが、Webはクロスプラットフォームプラットフォームの選択です。 HTML/JavaScriptのフロントエンドとは、アプリケーションがほとんどすべてのクライアントプラットフォームで実行できることを意味します。ほとんどの場合、それが実際の目標でした。MacとPCのどちらであるか、OSのバージョンなどを心配する必要はありません。
もちろん、一般的にはサーバープラットフォームを指定することになりますが、それだけの場合は特に、ほとんどの企業が既にWindowsサーバーとLinuxサーバーの混在をサポートしている今日、人々はより柔軟になります。
個人的には、Javaは依然として選択可能なクロスプラットフォーム言語であり、しばらく（Webアプリケーションと一緒に）そこに残る可能性が高いと思います。私はこの投稿でこのトピックについてさらに書きました 選択したプラットフォームとしてのJava ですが、特にクロスプラットフォームのフロントでは：
依存関係に注意している限り（JNIを使用してネイティブコードとインターフェースするライブラリを回避するなど）、Javaは、すべての主要なJVMプラットフォームで変更せずに実行できます
Beacuse Javaは通常、マシンに依存しないバイトコードとして配布されるため、任意のJVMで再コンパイルなしでを実行できます（ローカルJVM自体がネイティブコードへのJITコンパイルを処理するため）。たとえば、Windowsで開発した後、Macで同じjarファイルを使用して、合理的な複雑なGUIアプリを初めて実行することに成功しました。他のほとんどのクロスプラットフォーム言語とは対照的です。通常、異なるライブラリや異なるプラットフォーム用の再コンパイルが必要です。
必要なコアライブラリの多く（GUI、ネットワーキング、IOなど））は標準ランタイムの一部であり、クロスプラットフォームの方法で記述されています。したがって、狩りに行く必要はありませんクロスプラットフォームライブラリのテストでは、必要なほとんどすべてのものがランタイム環境にすでに存在していることが保証されます。
私はあなたがそれらの選択肢を持っていると思います：
1）いずれかを使用
- コンパイルまたは
- 解釈言語。
2）コードをどのようにパッケージ化して配信しますか？
- 1つの「フロントエンド」、1つのバイナリ/スクリプト？
- 1つの「フロントエンド」、複数のバイナリ/スクリプト？
- 複数の「フロントエンド」、複数のバイナリ/スクリプト？
これらの選択は、パフォーマンス、コードの可視性および配布に影響します。
ソースコードを譲っていただけませんか？コンパイルされた言語はあなたのためかもしれません。コンパイルされた言語は、解釈された（JITされた）言語よりもマイクロベンチマークで優れたパフォーマンスを発揮するようです。また、Java、Python、Rubyなど）のランタイム環境に依存している場合、コードの配布が難しくなる可能性があります。
私は、最も人気のあるクロスプラットフォームデスクトップアプリケーションが、C/C++とクロスプラットフォームウィジェットライブラリを使用して「1つのフロントエンド、複数のバイナリ」に対応していることを発見しました。 、VLC。
私はノーと言うでしょう。 pythonおよびRubyは頻繁に使用されるため、クライアント側とサーバー側の両方でJavaScriptを使用します。私は.NETを個人的に使用しており、実行に問題はありません。 MacおよびLinux（Windowsで開発中）
-edit- LLVMが人気になっていると聞きましたが、それでも非常に小さいです。これにより、単一のバイナリでクロスプラットフォームC++を使用できるようになります。どうやらブラウザで実行されるようですが、domを変更したりjavascriptを呼び出したりできる例は見たことがありません。