ただし、この方法を利用するにおいて理解しておくべき点がいくつかあります。 Wrapper が JVM をシャットダウンするとき、きれいにシャットダウンするように アプリケーションへ直接呼び出しは行われません。 むしろ、Wrapper は JVM 内部から「System.exit()」メソッドを呼び出して JVM のシャットダウンさせます。 アプリケーションが独自のシャットダウン フックを登録している場合は、それが呼び出され、 アプリケーションが正常にシャットダウンする機会が与えられます。 その一方、もしシャットダウンフックが登録されていない場合、 コンソール（コマンドウィンドウ）から［CTRL］＋［C］のキー操作によるアプリケーション任意停止と 同じように動作し、アプリケーションを直ちに終了させます。 シャットダウンフックの有無に関わらず、いずれのケースでも、Wrapper 導入前の環境状態と同じ挙動をします。

通例、この種のアプリケーションは、スタートアップ時にサーバーソケットを開き、シャットダウンのキッカケになる接続待ち状態になります。 ［シャットダウン］あるい「stop」クラスが起動されると、 アプリケーションに接続することによって、シャットダウンのキッカケを引き起こします。

Wrapper は、インテグレーション方法１「start」クラスを使用してアプリケーションを起動し、 アプリケーションをシャットダウンする時間になると「stop」クラスの メインメソッドを呼び出すことによって、この種のアプリケーションで動作します。

インテグレーション方法３は、前述の２つの方法 （方法１：WrapperSimpleApp、方法２：WrapperStartStopApp） とは共には利用できないという難点がありますが、複雑さにも十分に耐えうるのも最大の特徴です。 このインテグレーション方法３は、スタートアップやシャットダウンのプロセス同様に、ユーザーコードで要求を受けたり、 直接的にシステム コントロール イベントへ応答を返したり、ユーザーコードの実行を許可する唯一の方法です。

もし、コーディングして機能を追加する必要がない場合には、方法１（WrapperSimpleApp）でシャットダウンフックを実装すること、 あるいは、シャットダウンクラスを実装することは、必要であれば追加すればいい程度のオプションとして考えれば良いでしょう。 「シャットダウン」クラスのメインメソッドは、アプリケーションのシャットダウンメソッドを 呼び出すのと同様に、シンプルです。

なお、ほとんどのケースでは、方法１（WrapperSimpleApp）や 方法２（WrapperStartStopApp）のヘルパークラスが、 適切なタイミングで、アプリケーションのスタートアップやシャットダウンの面倒を見てくれるので、 方法３（WrapperListener）でのコーディングで機能を追加する必要性は、ほとんどないと思われます。

ただし、この方法を利用するにおいて理解しておくべき点がいくつかあります。 Wrapper が JVM をシャットダウンするとき、きれいにシャットダウンするように アプリケーションへ直接呼び出しは行われません。 むしろ、Wrapper は JVM 内部から「System.exit()」メソッドを呼び出して JVM のシャットダウンさせます。 アプリケーションが独自のシャットダウンフックを登録している場合は、それが呼び出され、 アプリケーションが正常にシャットダウンする機会が与えられます。 その一方、もしシャットダウンフックが登録されていない場合、 コンソール（コマンドウィンドウ）から［CTRL］＋［C］のキー操作によるアプリケーション任意停止と 同じように動作し、アプリケーションを直ちに終了させます。 シャットダウンフックの有無に関わらず、いずれのケースでも、Wrapper 導入前の環境状態と同じ挙動をします。