- - PR -
APサーバへデプロイする際のソースのコンパイルについて
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-01-07 11:29
初めまして、Hiroと申します。
初めて投稿させていただきます。 どうぞ宜しくお願い致します。 件名について内容を補足しますと、 開発機で作成した最新の全ソースファイルを、 対象となるAPサーバへデプロイする前の段階で、 一括してコンパイルし直したいと考えており、その際の質問です。 ＜＜環境＞＞ 開発機 OS：Windows 2000 Professional 開発ツール：WebSphere Studio(Site Developer 5.1) JDKバージョン：1.3(開発ツールに附属のもの) APサーバ OS：RedHat Enterprise Linux ES(2.1) Webサーバ：WebSphere Application Server 5.0(J2EE1.3準拠) JDKバージョン：1.3(Webサーバに附属のもの) 具体的な質問を以下に挙げます。 Q1.JDKはサンが公開しているものや、 ソフトウェアベンダが独自に提供しているものがあるかと思いますが、 同じJDK1.3でも互換性については完全ではないのでしょうか？ もし完全ではない、又は好ましくないといった場合には、 開発機で作成したソースをコンパイルする際には、 APサーバと同一のJDKを用いてコンパイルしないと問題ということになりますか？ (j2ee.jarなど完全にAPサーバ依存のものに関しては、そちらのクラスパスを通してます) Q2.一応、サンのJDKと開発ツールのJDKを用いた場合における APサーバへのデプロイ&動作検証はどちらも正常動作が確認できました。 その際、Antを用いてコンパイル・アーカイブの作成などをバッチ化してます。 その中で、JDKの選択、クラスパスへのライブラリの追加などを行い、 恐らく開発ツールであるWebSphere Studioと同じ設定にしたはずなんですが、 (結果からすると、どこか違うか抜けているんでしょうが) 開発ツールからコンパイルしたクラスファイルと、 バッチからコンパイルしたクラスファイルのサイズが異なります。 (バッチでは、JDKの違いによるサイズの違いはありませんでした) それでも、開発ツールからでもバッチからでもAPサーバでの動作確認ができましたが、 このクラスファイルのサイズが異なるというのはどういう意味なのでしょうか？ Q1に関する回答に関連するものと思いますが、どれが信頼にたるものかが分かりません。 ※そもそもソフトウェアのライセンス的には、 コンパイル専用の開発機にWebSphere Studioを入れて、 そこで最終的なコンパイルをすれば問題はないかもしれませんが、 わざわざ開発ツールを起動し、ソースを最新にした後コンパイルするのが手間になるのと、 開発ツールに頼ったコンパイルでは、その他の場面で応用が利かないためです。 質問内容がもしかしたら根本的・初歩的なことかもしれませんが、 (Javaの仕組みをきちんと理解してないための問題など) 今回きっちり勉強したいと思いますので、 ご指導いただけましたら、宜しくお願い致します。 | ||||||||
|
投稿日時: 2004-01-07 12:15
unibon です。こんにちわ。
"Write Once, Run Anywhere." なので大丈夫です。と言うのは冗談ですが(冗談なのか  )、コンパイラのレベルでの互換性は、通常は気にしなくても良いです。わずかなコンパイラの非互換性やバグを気にするよりも、アプリケーションのバグやランタイムライブラリのバグを気にしたほうが良いでしょう。
ただし、もっとも、javac での -target オプションに相当する、クラスファイルのバージョン指定は正しく指定する必要があります。 一方で、とくに、ランタイムライブラリの互換性には注意されたほうが良いでしょう。原則としては上位互換性は保たれますが、下位互換性は保たれません。上位のバージョンに付属するライブラリ(に含まれるクラスやその中のメソッド)を使ってコンパイルしたクラスファイルを、それよりも下位のバージョンの環境で動かすと、NoSuchMethodError や NoClassDefFoundError が出ることがあります。したがって、コンパイラは何でも良いのですが、コンパイル時に使うライブラリの指定には注意しなければなりません。 これらについては以前に、 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=3770&forum=12 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=7061&forum=12 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=8363&forum=12 のスレッドに書いたことがあります。
Eclipse だとコンパイラは独自のものを持っているようであり、おそらく WebSphere Studio もこれと同様だと思います。クラスファイルのサイズが違うのは、コンパイラに委ねられた実装の違いによるものであり、互換性がないためではないはずです。心配ならば javap で解析されて、コンパイラに委ねられた実装による違いを超えるような大きな違いがないことを確認されると良いでしょう。 | ||||||||
|
投稿日時: 2004-01-07 13:29
こんにちは、質問をしておりましたHiroです。
unibonさん、早速のお返事有難うございます。 まだ、javacのtargetオプションや、 javapコマンドによる実行結果は確認できておりませんが、(後ほど確認してみます) コンパイラ・ランタイムライブラリに関する互換性についての考え方など大変参考になりました。 APサーバへデプロイするためのアーカイブの作成作業は、 一貫したコンパイル環境で行い、(決めうちした単一のJDK) 最終的な動作確認として、APサーバ上でのテストに重点を置いて行いたいと思います。 もやもやしていた点がだいぶ解消されました。 お忙しいところ、アドバイス有難うございます。 | ||||||||
|
投稿日時: 2004-01-07 13:33
ここだけ反応します。 Eclipseでは独自のインクリメンタルコンパイラを使っているようです。 これが生成したクラスファイルをそのまま本番環境で実行するのではなく、 一度本番環境上でコンパイルしなおす方が良いと思います。 LinuxであればSunのJDKを使われているのだと思いますが、わざわざ開発機上で SunのJDKでコンパイルし直す必要は無いと思いますよ。 | ||||||||
|
投稿日時: 2004-01-07 14:56
こんにちは、Hiroです。
Weblogicではセットアップ時にSunのJDKをインストール・設定しましたが、 WebSphereはソフトウェア内部にJDKを持っているみたいです。 そこにパスを通してあげれば、サーバ側でもコンパイルできるかもしれないですね。 一般的には、開発機側(又はWindowsプラットフォーム)でなくて、 本番機側(又はLinux/Unixプラットフォーム)でコンパイルしてデプロイするケースが多いのでしょうか？ (一般的というと語弊があるかと思いますが、皆さんの体験やお聞きする範囲という意味ですね) 私自身の経験や知識が乏しいため､参考にお聞きしたいです。 両者において大きなメリット・デメリットってあるんでしょうか？ (Windowsで管理する方が、他のプラットフォームに慣れてない場合には使いやすい、 本番機でコンパイルした方が信頼性が高いなど) | ||||||||
|
投稿日時: 2004-01-07 17:05
バンドルされているのでしょうね。 IBMはSunとは別に独自のJVM実装を持っていますから。 このようなことをやる背景には、クラスファイルの互換性の問題があります。 具体的には、違うバージョンのJDKで作られたクラスファイルには互換性が無い 場合があり、実行時にエラーが出てしまうということもあるためです。 これを避けるために実行環境で再コンパイルします。 ちなみに、私は開発環境がWindows XP Professionalで、実行環境がhp-ux 11iのの時に これを経験しました。hp-uxのJDKはSunのJDKをライセンスしてhpが独自に実装(移植？) したものなので、このようなことが起きるのです。なぜなら、SunのJDKとhpのJDKでは 同じバージョンが付いていてもその中身が異なるからです。例えば、hpのJDKでは バージョン1.2.2からHotSpotがサポートされていたりします。 私はこんなところですかね。 [ メッセージ編集済み 編集者: おばけ 編集日時 2004-01-07 17:08 ] | ||||||||
|
投稿日時: 2004-01-07 17:29
WebSphereは3.5と４しか使用したことはありませんが、 ＪＤＫはインストール済みのＪＤＫを使用するか、 ＩＢＭ製のＪＤＫを使用するか選択したはずです。
私の場合、開発環境と本番環境のＯＳが異なる場合は、 本番環境でクラスを作成することが多いですね。 ＯＳが同じ場合は開発環境でクラスを作成して、 本番環境にクラスだけ持っていくことが多いですね。 | ||||||||
|
投稿日時: 2004-01-07 17:43
unibon です。こんにちわ。
もしそうだとすると、たとえば Java Applet は、クライアントの種類ごとにコンパイルし直す必要がありますが、その点についてはどうでしょうか。 クラスファイルの形式やライブラリ内のクラス・メソッドの種類についても、上位互換性はあり、下位互換性がないことだけに注意すれば大丈夫だと思います。ただし、この確認が難しいことや、あるいはプログラムは一般にどんな不確定要素があるか分からないのでターゲットかそれに近い環境でコンパイル・ビルドするに越したことはないですが。
この現象は興味深いですね。具体的にはどのようなエラーになって現れるのかが気になるところです。 ＃やっぱり "Write Once, Run Anywhere." は夢? | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。