プラットフォームの独立性の正確な意味は何ですか？
プラットフォームの独立性の意味は何ですか？
私はJavaの場合を取り上げています。 Java Windowsプラットフォーム上に構築されたLinux上のアプリケーションを実行できますか？またはその逆ですか？
両方のオペレーティングシステムで同じ（または正確な）プログラミングアルゴリズムを使用できますか？
私の見解では、ファイルタイプは、ビデオ、画像、ドキュメントなど、プラットフォームに依存しません。
ソフトウェアのプラットフォーム非依存性とは、複数のプラットフォームでほとんどまたはまったく変更せずに同じコードを実行できることを意味します。
悪魔は詳細にあります：
- それはあなたが「プラットフォーム」として定義するものに依存します。場合によっては、これは特定のハードウェアマシン構成である可能性があります。それ以外の場合は、「汎用PC」である可能性があります。他の場合では、それは仮想マシンとランタイム環境である場合があります（Javaの場合）。
- 「完全に」プラットフォームに依存しないものは何もありません-あなたを捕まえることができるいくつかのコーナーケースが常にあります。たとえば、Javaでプラットフォームに依存しない
File.pathSeparatorを使用するのではなく、ファイルパスの区切り文字をハードコードする場合、コードはWindowsとLinuxの両方で機能しません。プログラマーとして、これらのことに注意し、可能な場合は常にプラットフォームに依存しないオプションを使用し、移植性を重視する場合は異なるプラットフォームで適切にテストする必要があります。 - 特定のプラットフォームには常に無視できないいくつかの制約があります。例としては、ファイル名の最大長やシステムで使用可能なRAMなどがあります。どれだけプラットフォームに依存しないようにしようとしても、制約が厳しすぎるプラットフォームで実行しようとすると、コードが失敗する可能性があります。
- 一部の言語はソースコードレベルでプラットフォームに依存しない（C/C++が良い例です）が、コードがコンパイルされるとプラットフォームの独立性を失うことに注意することが重要です（ネイティブコードはプラットフォーム固有であるため）。 Javaは、プラットフォームに依存しないバイトコードにコンパイルされるため、コードがコンパイルされた後でもプラットフォームに依存しません（ネイティブコードへの実際の変換は、JVMによってバイトコードがロードされた後で処理されます）。
- 言語の実装には、特定のプラットフォームでのみ発生するバグが時々あります。したがって、コードが理論的に100％移植可能であっても、別のプラットフォームでコードをテストして、異常なバグが発生していないことを確認する必要があります。
Javaの特定の場合：
Javacodeは、同じJavaアプリケーションまたはアルゴリズムという意味で、プラットフォームに依存しません。 （通常はJavaバイトコードにコンパイルされ、.jarファイルにパッケージ化されます）は、WindowsとLinuxで同じように実行されます。
Javaライブラリ（たとえば、すべてのNiceオープンソースツールセット）は、純粋なJavaで記述されている限り、通常プラットフォームに依存しません。ほとんどのライブラリは、プラットフォームの独立性を維持するために純粋なJavaを使用しようとしますが、これが不可能な場合もあります（たとえば、ライブラリが特別なハードウェアと直接インターフェースする必要がある場合、またはC/C++ライブラリを呼び出す必要がある場合）ネイティブコードを使用します）。
Javaプラットフォーム/ランタイム環境は、同じライブラリ（イメージ、ネットワーク、ファイルIOなど）が利用可能で機能しているという意味で、プラットフォームに依存しません。すべてのプラットフォームで同じように。これは、これらのライブラリを使用するアプリケーションを任意のプラットフォームで実行できるようにするために、意図的に行われます。たとえば、ファイルシステムにアクセスするJavaライブラリは、WindowsとLinuxが異なるファイル名パス区切り文字を使用していることを認識しており、これを考慮に入れています。もちろん、これは内部的にはランタイム環境がプラットフォーム固有の機能を利用することを意味するため、プラットフォームごとに異なるJREが必要です。利用可能なプラットフォームのリストは、Javaダウンロードサイトで確認できます。 http://www.Oracle.com/technetwork/Java/javase/downloads/jdk-6u26-download-400750 .html
JVM自体（つまり、JavaバイトコードのJITコンパイルおよび実行を担当するJava仮想マシン）は、プラットフォームに依存しません。多くのプラットフォーム（メインフレームから携帯電話まですべて）で利用できるという意味で。ただし、JVMの特定のバージョンは、基盤となる各プラットフォームが異なるネイティブ命令コードとマシン機能を考慮するために必要です（そのため、Linuxを実行できませんWindowsおよびVice Versa上のJVM）。 JVMは、上記のJavaプラットフォーム/ランタイム環境の一部としてパッケージ化されています。
全体として、Javaは、おそらくプラットフォームの独立性にほぼ近いと思われますが、ご覧のように、内部ではかなりのプラットフォーム固有の作業が行われています。
100％純粋なJavaコードとライブラリにこだわる場合、私の経験では、Javaは「効果的に」プラットフォームに依存しないと見なすことができ、一般にWrite Once Run Anywhereの約束を守ります。しかし、それでもテストする必要があります!!
そうです、プラットフォームに依存しないということは、同じプログラムが変更を必要とせずに、どのプラットフォーム（オペレーティングシステム）でも機能するということです。
Javaの場合、アプリケーションはJavaそれ自体がプラットフォームに依存しない仮想マシンで実行されます。これは実際のマシン間のインターフェースである必要があります（オペレーティングシステム）とJava作成したコード）.
ビデオ、画像などの場合、これらはドキュメントであり、アプリケーションのdataであるため、通常は本質的にプラットフォームに依存しません。
実際、プラットフォームの独立性を達成する手法は
- 中間プラットフォームの構築
- 必要なプラットフォームのそれぞれに中間のものを実装します（Javaなどの言語）。
または、プラットフォームごとにコードを記述してコンパイルすることもできます（C/C++）。私の意見では、これは一種のプラットフォーム独立性でもあります。このように、アルゴリズムはプラットフォームに依存しないと言えます。
あなたは、ファイルタイプの真のプラットフォーム独立性に関して正しいです。ただし、プラットフォーム非依存という用語は通常、ファイルには適用されません。
Javaは、オブジェクト指向のプラットフォームに依存しないプログラミング言語です。 javacコンパイラは、ソースコードをコンパイルし、バイトコード言語（ユニバーサル言語）を生成します。
この言語は、どのオペレーティングシステムでも理解できません。最初に処理する必要があります。ここで、特別な実行可能プログラム（JVM）がシーンに入ります。 JVMのインタープリターは、バイトコードを1行ずつ読み取り、バイトコード命令をマシン固有の理解可能な言語（最終的にはバイナリコード）に変換します。したがって、バイトコードはプラットフォームに依存しませんが、解釈されたコードはマシン固有であり、JVMがインストールされている環境で実行されます。 Javaプログラムがプラットフォームに依存しないことは、Javaがプラットフォームに依存しないことを意味します。
Sun MicroSystemsのスローガンは[〜＃〜] wora [〜＃〜]：Write Once Run Anywhereです。
JVMにはホストが必要なため、Javaプログラムはプラットフォームに依存していません。また、Java設計上の言語には、ファイルシステムに関する要件がありますシステムがFAT16パーティションを使用している場合、短いクラス名になります。
class FOOBAR
と同じです
class Foobar
と名前
class AbstractPrinterFactory
不可能です。
比較として、Cにはランタイム要件がほとんどないため、より高い移植性を提供できます。小さなCプログラムを本当にローエンドのデバイスにバックポートすることはまだ可能です。