Java SDKインストーラーがJava_HOMEを設定しないのはなぜですか？
Java SDKをインストールした後、なぜJava_HOME環境変数を手動で設定する必要があるのかといつも思っていました。
Java_HOME = c：\ Program Files\Java\jdk1.6.0_12
Visual Studioは、少なくとも次の種類の環境変数を設定するためのバッチファイルを提供します。
「c：\ ProgramFiles\Microsoft Visual Studio9.0\VC\vcvarsall.bat」を呼び出します
Javaに似たようなものはありますか？Java SDKをインストールした後に簡単に機能するビルドスクリプトを作成しようとしています。人々にそうしてほしくないPC上の環境変数を台無しにします。
Javaのバージョンはいくつでもインストールできます。
セットアップがJava_HOMEなどのlocal環境変数を変更するのは危険です。 、既存のJavaインストールを参照する可能性があるため。
これは、主張されている「プラットフォーム依存の問題」とは何の関係もありません。 ;）
スクリプトはJava_HOMEに依存して起動する可能性があるため、これも新しいJavaインストールでJava_HOMEを変更する場合は悲惨です。これらのスクリプトはすべて突然必要になります。互換性がない可能性のある新しいJVMで起動しました。
さらに、パスに$Java_HOME/binまたは%Java_HOME%/binを設定することで、Java_HOMEを使用したいバージョンのJava）に動的に変更できます。 PATH変数を使用します。
Michael Borgwardt コメントで興味深いフォローアップの質問をしました
それでも、これは、以前にJava_HOMEがまったく設定されていないのに、インストーラーがJava_HOMEを設定しない理由を説明していません。
答えは簡単です：
セットアップは、スクリプトがすでにJava_HOMEに依存しているかどうかを知ることができません。
意味：一部のスクリプトはJava_HOME値をテストでき、設定されていない場合は、他の場所にインストールされている別のJVMを参照します（「インストール」によって参照できるのは「コピー済み」のみであることを忘れないでください。JDK/ JREはセットアップによって常にインストールされるとは限りません）
Java_HOMEを設定すると、一部のスクリプトのデフォルトの動作が中断される可能性があります。
Env varが設定されていないことに依存する架空のスクリプトを邪魔したくないのは、私には無意味に妄想的に聞こえます-スクリプトがそれを行う場合、インストール時に別のJVMを使用することを明らかに望んでいます-それを回避する理由はありません。
うーん...甘い。毎日のように大規模なデプロイメントの問題に対処するために（私の店の内部アプリケーションの場合）、私はあなたに保証することができます：それは非常に正気の「妄想」です持っていることを扱います。
（非常に）大規模なユーザーのセットにデプロイする場合、そのプラットフォームと構成について何も想定したくありません。 「明らかにWANTS」は、私があえてするつもりはない（または私の電話をあなたの電話にリダイレクトする;）、そしてあなたが怒った電話を処理するという仮定です。
たとえば、Sunの1.4.2 JVM（Java_HOMEは開発プラットフォームに設定されておらず、デフォルトのパスはスクリプトで直接設定されています）、またはJRockitの1.4.2（Java_HOME set、as）で起動するスクリプトが多数あります。これは、統合、プリプロダクション、およびプロダクションプラットフォームの対象です）。
ただし、Eclipseの起動に使用するため、新しいJDK1.6.xを定期的にインストールします。
それらのスクリプトがJava_HOMEセットを必要とし、何も機能しなくなったと仮定します。
...これに Robert Grant はこの場で批評家になります：
1つの特定のバージョンを必要とするスクリプトについて説明していますが、それでもグローバルJava_HOMEを調べています。それはひどく考え抜かれたスクリプトです。
それは真実かもしれないしそうでないかもしれないが、それはまた私の主張を正確に示している：
「仮定をしたくない」：プラットフォーム/設定についての仮定も、「ベストプラクティス」についての仮定もありません。
前者はパラノイアに聞こえるかもしれませんが、後者は明白な常識です。ユーザーがスクリプトを「正しく」考えたので、製品（ここではJDKセットアップ）がユーザーの環境で何も壊さないと考えています。 。非常識だろう。
GvS 提案：
または、それを実行するオプションがあり、デフォルトで無効になっている可能性があります
これは、セットアップ画面に含める別のオプションを意味します。このオプションは、ユーザーが注意深く確認する必要があり、ユーザーが自分のしていることを知っていると思って選択した場合でも、意図しない結果をもたらす可能性があります...
それは単にそれだけの価値がありません。
Java_HOMEは、Sunによって発明またはサポートされている規則ではないと思います。
彼らはおそらく、CLASSPATH環境変数**であった大失敗をよく覚えており、環境変数から地獄を遠ざけることを好みます。
**これは、以前のJava SDKおよび文献でJVMクラスパスを設定するための主要な方法として推奨され、ユーザーとさまざまなアプリケーションが環境変数をいじり、互いの変更を上書きし、依存する結果になりました。相互に矛盾する内容について。
vcvarsall.batメカニズムは、Visual C++がユーザー/システムの環境変数をいじることなく、コンソールに正しい変数を提供するための便利な方法です。ただし、Installshieldがコードをシステムに取り込む唯一の方法であると想定しています。 JDKは、ある場所から別の場所にカットアンドペーストされることを許容する必要があります。
Java.exeを探している場合、Installshieldインストーラーはそれを％windir％\ system32に配置する必要があるため、PATHで使用できます。
レジストリにクエリを実行すると、インストールされているアプリの場所に関するヒントを得ることができます。
C:>REG QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6" /v JavaHome
! REG.EXE VERSION 3.0
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Development Kit\1.6
JavaHome REG_SZ C:\dev\Java\jdk1.6.0_05
ただし、これはベンダー、バージョン、およびインストールメカニズムについていくつかの仮定を行うため、これに完全に依存することはできません。
これは、私のようにここにたどり着く他の誰かを助けるかもしれません。 Javaをツールとして使用し、生き方として採用したくないので、Java_HOMEがどのように設定され、なぜ正しくないのかを知る必要がありました。答えは判明しました。 WinAntインストールはJava_HOMEを（ANT_HOMEと共に）設定しますが、現在インストールされているJavaにのみ基づいています。したがって、Javaのバージョンを変更する必要があり、Antを使用している場合、正しい方法はWinAntをアンインストールすることです。 、Javaをアンインストールし、新しいJavaをインストールしてから、WinAntを再インストールします。
インストーラーがプラットフォームに依存する問題を明確に解決するため、これがなぜであるかはわかりません（もちろん、これはJVMの要点です）。 JREとJSDKを混在させていませんか？
プログラムがJavaがインストールされている場所（私が推測するスクリプト））を検索し、Java_HOMEを設定して、パスに追加する方法があるかもしれません。
IBMはすでにこのトリックを行っているようです： http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg2119922
JREとJSDKのインストールの違いを示唆するその他の興味深い投稿： http://confluence.atlassian.com/display/CONF26/Set+Java_HOME+variable+in+Windows
お役に立てれば。