Java SDK をインストールした後、なぜ JAVA_HOME 環境変数を手動で設定しなければならないのか、いつも疑問に思っていました。
JAVA_HOME=c:\Program Files\Java\jdk1.6.0_12
Visual Studio は少なくとも、次の種類の環境変数を設定するためのバッチ ファイルを提供します。
「c:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat」を呼び出します
Javaには似たようなものがありますか？Java SDK のインストール後に簡単に動作するビルド スクリプトを作成しようとしています。PC の環境変数をいじってほしくないのです。
Javaのバージョンはいくつでもインストールできます。
セットアップが既存のJavaインストールを参照する可能性があるため、などのローカル環境変数を変更することは危険です。JAVA_HOME
これは、「プラットフォームに依存する問題」とは何の関係もありません。;）
スクリプトは自分自身を起動することに依存している可能性がJAVA_HOMEあるため、これも、新しいJavaインストールを変更するJAVA_HOMEのは悲惨です。これらのスクリプトはすべて、互換性がない可能性のある新しいJVMを使用して突然起動する必要があります。
さらに、$JAVA_HOME/binまたはパスを設定することにより、PATH変数をあまり使用せずに、使用するJavaのバージョンに%JAVA_HOME%/bin動的に変更できます。JAVA_HOME
Michael Borgwardtは、コメントで興味深いフォローアップの質問をしました
それでも、これは、以前に設定されていないのにインストーラーが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意図されたターゲットであるため、設定されています）で起動するスクリプトが多数あります。統合、プリプロダクション、およびプロダクションプラットフォームについて）。
ただし、Eclipseの起動に使用するため、新しいJDK1.6.xを定期的にインストールします。
それらのスクリプトがそれらのJAVA_HOMEセットを必要としていると仮定します...そして何ももう機能しません。
... ロバート・グラントがこの現場の批評家にしたのは：
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 = swg21199220
JREとJSDKのインストールの違いを示唆するその他の興味深い投稿：http： //confluence.atlassian.com/display/CONF26/Set+JAVA_HOME+variable+in+Windows
お役に立てれば。
私は、Javaがプラットフォームに依存することを何もしたくないと思います。Windowsでは、クラスパスはLINUX/UNIXとは異なる方法で設定されます。