Java（まだ）はクロスプラットフォーム言語の選択ですか？[閉まっている]

90年代にJavaを使い始めたときは、初日からすべて「一度書くだけでどこでも実行できます」でした。当時はおそらくそれがすべて真実で、私も合唱団の一員でした。

マルチプラットフォームランタイムを使用する他のすべての言語（python、flash、perl、html、php ...）を考慮して、これについてどう考えるかはもうわかりません。しかし、Javaはクロスプラットフォーム開発に向いていると思われるため、Javaを使用する必要があるという多くの議論がまだあります。

それで、それは今日でも本当ですか？Javaは今でもマルチプラットフォーム開発に最適な言語ですか？

• クロスプラットフォームの側面に焦点を当てて具体的に説明してください。
• 一般的な言語機能の比較は求めていません。

更新：これまでのところ素晴らしい反応です！ほとんどの答えは、JavaまたはWebを支持しているようです。スクリプト群衆からの入力はありますか？

Pythonなどのスクリプトスタイル言語も、クロスプラットフォーム開発を容易にします。さて、あなたがPython（または他のそのような言語）を好むかどうかはあなた次第であり、おそらくここでその議論を始める必要はないでしょう。

Javaは移植性のあるコードを書くことを強制しようとしますが、Pythonでは移植可能なコードを書くことができます。実際のPython言語自体は移植可能ですが、外部ライブラリは実行される場合とされない場合があります。さらに、Pythonはプラットフォーム固有のサービスへのアクセスを自由に提供します。

そこでJavaには利点がありますか？どちらの場合でも、同様の簡単さで移植可能なコードを書くことができると思います。つまり、コードを記述でき、通常は異なるプラットフォームで動作します。しかし、コードを書いて、それがどこでも動作すると仮定するだけで済ますことはできません。私は、Windows、Linux、およびMac用のバージョンを作成するpythonプロジェクトに取り組みましたが、クロスプラットフォームの問題はほとんど発生しませんでした。（私が覚えているのは、pygameを使用していたライブラリのバグで、Linuxで描画の問題が発生したためです。これは、使用したpygameのバージョンをアップグレードすることで修正されました）

別の問題は展開です。コードを実行するスタンドアロンプ​​ログラムを配布する場合は、プラットフォームごとに異なるバージョンを作成する必要があります。Javaの場合、1つのバージョンを配布し、ユーザーにJavaがインストールされているか、インストールできると想定できます。この場合、おそらくJavaはデプロイメント部門の単純さで勝ちます。

最終的には、どの言語で作業するのが好きで、どの種類の展開を実行する必要があるのか​​と思います。

Javaはないかもしれないがまたは唯一の実行可能なクロスプラットフォームのツール、それはいくつかの長所があります：

• 非常に高速です。
• それは非常に堅牢です。
• 非常にポータブルです（たとえば、10年前にWindows 95でコンパイルされたバイトコードは、今日のOS Xでも問題なく動作します）。

そしていくつかの弱点：

• コアGUIライブラリ（Swing ...）は、その時代を示しています（サードパーティの追加がここで役立ちます）。
• 言語自体はそれほど冗長ではありません（チェック例外など）。
• 起動時間はより速くなる可能性があります（ただし、常に改善されています）。

プラットフォーム Javaについて具体的に説明すると、もう1つ重要な点があります。

• ありますかなりの数の JVMと上で実行することの言語相互運用のJavaとは。

それは当時と同じように今日も真実です-それは完全ではないということです。Javaは一度書くだけで、どこでもテストとデバッグができます。確かに、完全に新鮮なポートよりもはるかに少ない作業ですが、一般的に最初の誇大広告が信じていたよりも多くの作業です。

この製品には、WindowsまたはLinuxで実行されるJavaサーバーがありますが、OS固有の問題があり、必要に応じてLinuxサーバーとWindowsサーバーの両方をサポート/テストできることを確認しています。Java UIはサーバーよりも多くの問題を抱える傾向があります（ただし、多くは外観上のものであるため、アプリケーションによっては無視できる可能性があります）。

私にとって厳密な言語ではありませんが、ウェブはクロスプラットフォームのプラットフォームです。HTML / JavaScriptフロントエンドとは、アプリケーションがほとんどすべてのクライアントプラットフォームで実行されることを意味します。ほとんどの場合、それは本当の目標でした。MacかPCか、OSバージョンなどを気にする必要はありません。

もちろん、通常はサーバープラットフォームを決定しますが、特にほとんどの企業が既にWindowsサーバーとLinuxサーバーの混在をサポートしている今日では、人々がより柔軟になります。

個人的には、Javaは依然としてクロスプラットフォーム言語の選択肢であり、（Webアプリケーションとともに）しばらくの間そこにとどまる可能性が高いと思います。この投稿では、Javaを選択のプラットフォームとして取り上げていますが、特にクロスプラットフォームの分野では、次のトピックについて詳しく説明しました。

• 依存関係に注意を払っている限り（たとえば、JNIを使​​用してネイティブコードとインターフェイスするライブラリを避ける）、すべての主要なJVMプラットフォームでJavaを変更せずに実行できます。

• Javaは通常、マシンに依存しないバイトコードとして配布されるため、JVMで再コンパイルせずに実行できます（ローカルJVM自体がネイティブコードへのJITコンパイルを処理するため）。たとえば、Windowsで開発した後、同じjarファイルを使用してMacで初めて実行する合理的な複雑なGUIアプリを取得することに成功しました。これとは対照的に、他のほとんどのクロスプラットフォーム言語は、通常、異なるライブラリを必要とするか、異なるプラットフォーム用に再コンパイルする必要があります。

• 必要なコアライブラリ（GUI、ネットワーク、IOなど）の多くは、標準ランタイムの一部であり、クロスプラットフォームの方法で記述されています。そのため、クロスプラットフォームライブラリを探してテストする必要はありません。必要なもののほとんどが、ランタイム環境にすでに存在していることが保証されます。

これらの選択肢があると思います：

1）いずれかを使用

• コンパイルまたは
• 通訳言語。

2）コードをどのようにパッケージ化して配信しますか？

• 1つの「フロントエンド」、1つのバイナリ/スクリプト？
• 1つの「フロントエンド」、複数のバイナリ/スクリプト？
• 複数の「フロントエンド」、複数のバイナリ/スクリプト？

これらの選択は、パフォーマンス、ソースコードの可視性、および配布に影響します。

ソースコードを配布してもよろしいですか？コンパイルされた言語はあなたのためかもしれません。コンパイルされた言語は、解釈された（JITされた）言語よりも、マイクロベンチマークで優れたパフォーマンスを発揮するようです。また、Java、Python、Rubyなどのランタイム環境に依存している場合、コードの配布が難しくなる可能性があります。

最も人気のあるクロスプラットフォームデスクトップアプリケーションは、C / C ++とクロスプラットフォームウィジェットライブラリ（Audacity、Blender、Firefox、Google Earth、OpenOffice、Skype、Songbird、Stellariumなど）を使用して「1つのフロントエンド、複数のバイナリ」 VLC。

私はノーと言います。pythonとrubyは頻繁に使用され、クライアント側とサーバー側の両方のjavascriptも使用されます。私は個人的に.NETを使用していますが、MacやLinuxで（Windows上で開発中に）実行するのに問題はありません

-編集-LLVMが普及しつつあると聞きましたが、まだ非常に小さいです。これにより、単一のバイナリでクロスプラットフォームC ++を使用できます。どうやらブラウザで実行されますが、domを変更したりjavascriptを呼び出したりできる例を見ていない。

モバイルプラットフォームを組み合わせて使用​​する場合は、少なくとも再コンパイルも含める必要があります。例えば、アンドロイド、j2me。