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

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

この種のアプリケーションを持つ環境下では、 アプリケーションを起動させる時には、最初のメソッド［start］クラスを呼び出したり、 アプリケーションのシャットダウン時には、［stop］クラスのメインメソッドを呼び出したり、 Wrapper は「クラスの呼び出し」で動作します。

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

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

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

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