読者です 読者をやめる 読者になる 読者になる

batファイルからJavaコマンド実行(続き)

batch java error

昨日に引続き。

batファイルからJavaコマンド実行

 

本日、改めて開発機の状況と原因っぽいのが明瞭になったので書いてみます。

昨日の記事に追記してもよかったのですが、少し長くなったので分けました。

 

開発機の状況

インストールされたJava

  • (JDK 1.7.0 Update 51 32bit) C:\Java\jdk1.7.0_51x86\bin\java.exe
  • (JDK 1.7.0 Update 55 64bit) C:\Java\jdk1.7.0_55\bin\java.exe
  • (JRE 1.7.0 64bit) C:\Program Files\Java\jre7\bin\java.exe
  • (JRE 1.7.0 64bit) C:\Windows\System32\java.exe

JDKの32bitと64bitが1つずつ、JREが1つに、コピーされたJRESystem32フォルダにも存在していました。

OSは64bitなのですが、32bitのJDKSQL Developerを使うためにインストールしています。

Windows 7 Professional 64bitでのSQL Developerの設定 | Developers.IO

64bitのJDKは開発用。64bitのJREはセキュリティチェックのために最新版を維持させています。

環境変数のPath

  • 標準で通しているC:\Windows\System32のみ

自分でも驚きましたが、PC移行などを行ってから環境変数に通す作業を行っていなかったようです。

ただ、JREインストール時にSystem32フォルダにコピーされるjava.exeがあるためjavaコマンドは実行できるようです。

java.exe の実行パスに環境変数 PATH の設定が反映されない(Windows) - happynowの日記

batファイルからJavaコマンド実行

環境変数のPathに登録

最初の確認として、System32フォルダ以外のjava.exeにはPathが通っていない状態です。

System32フォルダより前にPathを読むよう先頭に3つのjava.exeがあるフォルダを1つずつ通して確認してみると、いずれもbatファイルからJavaコマンドが実行できるようになりました。

java.exeがあるフォルダで実行

次に、batファイルの冒頭でcdコマンドを使ってそれぞれのフォルダに移動してからJavaコマンドを実行してみました。

C:\Java\jdk1.7.0_51x86\bin

C:\Java\jdk1.7.0_51x86\bin>java -version
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) Client VM (build 24.51-b03, mixed mode, sharing)

C:\Java\jdk1.7.0_55\bin

C:\Java\jdk1.7.0_55\bin>java -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

C:\Program Files\Java\jre7\bin

C:\Program Files\Java\jre7\bin>java -version
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)

C:\Windows\System32

C:\Windows\System32>java -version
'java' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

おっとー? System32フォルダのjava.exeがめちゃめちゃ怪しいです。

何が違うんだろうと思いながら調べてみると、setコマンドで色々と情報が取得できることを知りました。

コマンドプロンプトからの実行とbatファイルからの実行でsetコマンドの結果を比較してみると、以下の違いがありました。

コマンドプロンプト
PROCESSOR_ARCHITECTURE=AMD64
batファイル
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64

このPROCESSOR_ARCHITECTUREを調べてみると以下の記事を見つけました。

環境変数を使ってプロセスが 64bit か 32bit か判別する : もやもやプログラミング

どうも、普通に呼び出したコマンドプロンプトとbatファイルをダブルクリックで開いたときのコマンドプロンプトはbit数が異なるようです。

 

じゃ、bit数が異なると何が起こるとかといいますと。

個人的な φ(`д´)メモメモ…: 64bit版のWindowsで32bitアプリケーションからsystem32ディレクトリのファイルを開けない

64bit OSで32bitのアプリケーションからSystem32フォルダにアクセスしようとすると開けないファイルが存在するそうです。

これで、同時にMDIEから見たときにSystem32フォルダのjava.exeが見えない原因も分かりました。地味にすっきり。MDIEは32bitアプリケーションでした。

なお、アプリケーションのbit数はタスクマネージャのプロセスで確認することができます。プロセス名の末尾に*32がついていれば32bit、無ければ64bitです。

 

最後に、これで実行してみました。

C:\Windows\Sysnative

C:\Windows\Sysnative>java -version
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)

はい、解決です。

 

 

今回の顛末とましては、通常は64bitで動くコマンドプロンプトがbatファイルから実行した場合には32bitで動くため、Java環境変数PathがSystem32フォルダにしか通っていないとコマンドが認識できない、ということでした。

すごい勉強になりました。