6

これは何度も質問され、答えられてきた質問かもしれませんし、そうあるべきですが、私は答えを見つけることができません。

コンパイルされたアプリケーションをサーバーで実行している場合、ローカルマシンでアプリケーションをコンパイルし、ローカルマシンでコンパイルしたクラスをサーバー上のクラスと交換できますか？

つまり、コンパイルされてサーバー側にあるファイルを、コンパイルされてローカルマシンにあるほぼ同じファイルに置き換えることはできますか？

サーバー側のバージョンでは、他のファイルにハードコードされた接続がいくつかあり、すべての場所がわからないため、アプリケーション全体の再コンパイルを行うのではなく、必要な1つのファイルのみを交換したいと思います。 。

4

3 に答える 3

6

あなたの質問に対する答えは「はい」です。クラスファイルを置き換えることはできますが、他の依存関係が変更されていないことを確認する必要があるという点で、やや複雑です。

たとえば、コンパイルしているクラスに、他のクラスで使用されているメソッドのメソッドシグネチャの変更が含まれている場合は、それらも置き換える必要があります。public、protected、またはdefaultメソッドのメソッドシグネチャが変更されない限り、問題はありません。

補足として、これが頻繁に行うことである場合、オブジェクトが個々のパラメーターではなくメソッドに渡されることが多い理由をすぐに理解できます。

public MyObject getObject(MyObject2 mySecondObject)

vs

public MyObject getObject(int a, int b, int c)

メソッドに渡されたオブジェクトに新しいプロパティを追加する必要がある場合、メソッドシグネチャは変更されませんが、メソッドシグネチャ自体にパラメータを追加または削除すると、すべての依存関係に連鎖反応が発生するため、これらのクラスファイルもコンパイルして置き換えます。

強調する最後のポイントとして、プライベートメソッドまたはプライベート変数に加えた変更、あるいはメソッドの定義でさえ、他のクラスファイルに影響を与えたり影響を与えたりしないことに注意してください。重要なのは、入力と出力が常に同じデータ型を受け取り、返すという点で、メソッドが他のクラスと持っている契約を守ることだけです。

これは、インスタンス変数のカプセル化の重要性と、それらの依存関係が他のクラスからどのように隠されているかを強調しています。

于 2012-05-07T09:38:54.013 に答える
2

はい、できます。さらに、ホットスポットのため、クラスは実行時に再ロードされるため、サーバーを再起動する必要はありません。これは、開発サイクル中に非常に役立ちます。

ただし、1つの別個のクラスを置き換える場合は注意が必要です。クラスに環境内で変更された他のクラスへの参照がある場合、サーバーでの置換は失敗します。

于 2012-05-07T09:37:40.143 に答える
1

「オフライン」置換について話していると思います（つまり、サーバーを再起動できます）。

この場合、次の解決策が実行可能です。Javaはクラスパス変数を使用します。そこで、プロセスがファイルを検索する一連のjar/フォルダーを定義します。

したがって、次のことができます。

  1. 新しいクラスを作成し（同じ名前で同じパッケージに存在する必要があります）、コンパイルします。

  2. 更新したクラスを保存する予定のフォルダーをサーバー上に作成します。

  3. クラスパス変数を更新して（おそらくアプリケーションの起動スクリプトで）、このフォルダーが残りのクラスの前に表示されるようにします。

  4. サーバーを再起動します。これで、新しいクラスが古いクラスの前に解決され、ロードされます。

注意：これは、「スタンドアロン」アプリケーション、および一般にカスタムクラスローダーをいじらないアプリケーションで機能します（たとえば、これはアプリケーションサーバーの場合です）。

より複雑な解決策は、（私が説明したように）そのようなフォルダーを調べてそこからリソースをロードしようとするクラスローダーの定義に基づくことができます。

お役に立てれば。

于 2012-05-07T09:38:49.343 に答える