デバッグ

ボクシング変換とMapのキー

凪瀬 — Mon, 02 Mar 2009 21:59:00 GMT

今日はまったバグ。

Map<Long, String> map = new HashMap<Long, String>(); map.put(1L, "1"); System.out.println(map.get(1)); System.out.println(map.get(1L));

キーに1 (ボクシング変換でIntegerになる)を渡した場合と1Lを渡した場合で挙動が異なるというオチ。Map.get()の引数がObjectなので両方受け付けちゃうんですね。

Seaserのホットデプロイとリフレクション

凪瀬 — Tue, 17 Jun 2008 15:39:00 GMT

Seaserのホットデプロイは開発向けにはなかなか便利ですが、これを使えるようにフレームワークの構成を考えるのはかなりしんどいものがあります。今回はハマったポイントとしてリフレクションを取り上げます。

Seaserのホットデプロイ

Seaserのホットデプロイは実行時に特定箇所でクラスローダを毎回新しくするというシンプルなものです。

結構、割り切った作りになっているなぁというのが感想ですが、そのシンプルさと原理からいろいろと制限事項も生まれてしまう。

今回、私がハマったところはフレームワーク内でリフレクションをする際に、クラスローダの違いからClassCastExceptionを出したり、NoSuchMethodExceptionを出したりしたことでした。

クラスローダの基礎知識

まず、基礎知識としてクラスローダが違う場合、同じClassでも代入互換性がありません。Classの同一性は、Class自身とそのクラスローダによって定められます。

次に、クラスローダは階層構造をなしていて、まず親クラスローダにロード処理が移譲されます。

ClassLoader

ClassLoader クラスは、委譲モデルを使ってクラスとリソースを探します。ClassLoader の各インスタンスは、関連する親クラスローダーを持ちます。クラスまたはリソースを見つけるために呼び出されると、ClassLoader インスタンスはそれ自体でクラスまたはリソースの検索を試みる前に、その検索を親クラスに委譲します。「ブートストラップクラスローダー」と呼ばれる仮想マシンの組み込みクラスローダーはそれ自体では親を持たず、ClassLoader インスタンスの親として動作します。

このため、親が同じである場合は、同じクラスローダ(つまるところ親)で読み込まれることで代入互換を持つことがあります。

クラスローダを跨ぐ場合のClassCastException

Seaserのホットデプロイは HotdeployUtilのstart()とstop()の間でクラスローダが変わることで実現しています。

なので、この区間の中と外ではクラスローダが異なります。そのため、戻り値のClassCastExceptionが発生することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); System.out.println(o.getClass().getClassLoader()); Hoge hoge = (Hoge)o; HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. org.seasar.framework.container.hotdeploy.HotdeployClassLoader@6e70c7 Exception in thread "main" java.lang.ClassCastException: test.logic.impl.TestLogicImpl cannot be cast to test.Hoge at test.LoaderTest.main(LoaderTest.java:19)

こうした再読込をおこなうタイプのクラスローダは親クラスローダへの委譲を行わないことで実現できます。親へ委譲してしまうと読み込み済みのクラスをリフレッシュすることができません。

しかし、この場合、クラスローダ越境ができなくなります。通常は、親への委譲を先に行うことで、共通して読み込まれるクラスには互換があったわけですが、クラスをロードしなおすために、親への委譲を行わないようにすると、上記例のようにClassCastExceptionとなってしまうのです。

リフレクションの際のメソッドシグネチャにも注意！

こうしたクラスローダを跨いだ箇所でリフレクションを行っていると、わかりにくいバグに遭遇することがあります。

SingletonS2ContainerFactory.init(); S2Container container = SingletonS2ContainerFactory.getContainer(); HotdeployUtil.start(); Object o = container.getComponent("testLogic"); Method[] ms = o.getClass().getMethods(); System.out.println(Arrays.toString(ms)); Method m = o.getClass().getMethod("setHoge", Hoge.class); HotdeployUtil.stop();

log4j:WARN No appenders could be found for logger (org.seasar.framework.container.factory.S2ContainerFactory). log4j:WARN Please initialize the log4j system properly. [public void test.logic.impl.TestLogicImpl.setHoge(test.Hoge), public test.Hoge test.logic.impl.TestLogicImpl.getHoge(), public native int java.lang.Object.hashCode(), public final native java.lang.Class java.lang.Object.getClass(), public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException, public final void java.lang.Object.wait() throws java.lang.InterruptedException, public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException, public boolean java.lang.Object.equals(java.lang.Object), public java.lang.String java.lang.Object.toString(), public final native void java.lang.Object.notify(), public final native void java.lang.Object.notifyAll()] Exception in thread "main" java.lang.NoSuchMethodException: test.logic.impl.TestLogicImpl.setHoge(test.Hoge) at java.lang.Class.getMethod(Unknown Source) at test.LoaderTest.main(LoaderTest.java:24)

ご覧のように、setHoge(Hoge)が存在しているにも関わらず、NoSuchMethodExceptionが投げられsetHoge(Hoge)はない！と言われてしまうのです。これは、getMethod()の引数に渡すHoge.classと、読み込まれたコンポーネントのHoge.classでクラスローダが異なるためです。

開発用と割り切って全体を囲ってしまう

クラスローダの越境は非常に厄介ですので、処理の頭からお尻までまるごとクラスローダを差し替えるように使うのが無難です。

Servletであれば、ホットデプロイ用の HotdeployFilter が用意されていますのでそちらでリクエストの全体で差し替えるほうがよいでしょうね。

タスクマネージャではJavaのメモリ使用量は測れない

凪瀬 — Tue, 04 Dec 2007 15:30:00 GMT

@ITより。 Javaのメモリ消費量について調査する際にWindowsのタスクマネージャでJava VMの使用しているメモリ量を見ても駄目だという話。

メモリリークの調査だとか、使用する資源量の調査だとか、いろいろな理由があってメモリ消費量を計測したいという話はあちこちで見かけます。ことJavaの場合、メモリはOSから直接供給されるのではなく VMが間に入って管理を行うためOSからプロセスの消費しているメモリ量を見ても実態がつかめないことをまず理解せねばなりません。

オブジェクトがGCされてもメモリ消費量が減らない！と騒ぐ前に

JavaのVMはメモリが必要になったときにその都度OSにメモリを供給してもらうわけではありません。

ある程度まとまった量のメモリをOSから貰い、それをプールとして、オブジェクトがnewされるたびに分割して供給するわけです。そして、オブジェクトの参照がなくなってGC(ガーベッジコレクション)によって回収された場合にも、プールに戻すだけでOSに細かく返していくわけではありません。

そのため、オブジェクトを作ったり解放したりを繰り返しているJavaプログラムを動かしていても、 Windowsのタスクマネージャから見るとメモリ量は変わらないことがあります。タスクマネージャから見ているのはVM全体が確保しているメモリだからです。

JavaのVM内でのメモリの使用状況を確認するには

簡素な方法としては、 java.lang.Runtime#freeMemory()を使う手法です。
この値をSystem.out.println()で出力することで、そのときの空き容量を得られますからコードを直接いじりながらデバッグしているような段階では手軽に計測できますね。

ツールを使う場合は jconsole を用います。これはJDKに付属しているツールですので別途ダウンロードする必要はありません。

ミニマムコードの書き方

凪瀬 — Sun, 02 Dec 2007 19:37:00 GMT

技術系のコミュニケーションにはミニマムコードは欠かせません。現象を100の言葉を並べて説明するよりも動作するプログラムを1回動かしてもらう方がよく理解してもらえるのです。まさに百聞は一見に如かずといったところでしょう。

ミニマムコードに求められること

ミニマムコードとはなんでしょうか？「ミニマム」＋「コード」ですから、最小限のコードといった意味合いです。最小限だけれども、それだけで動作する完全なプログラムである必要があります。該当部分のコードの抜粋とは違うのです。

それだけで動作するコードであること
テーマを再現できること
テーマ以外が極力含まれないコードであること

テーマと言っているのは、その時々で話題にしている議題のことです。ある現象について話しているならその現象を起こせるコードということです。コードは余計なものが含まれていないことが理想的です。

余計なコードがあると、本来テーマにしたい部分が埋もれてしまいます。コードを隠すならコードの中というわけです。論点をはっきりさせるために、関係ないところはそぎ落とします。設定ミスなどの場合、そぎ落としていく過程で何が悪かったのかが分かることがあります。最小限だと動くのに、本番のコードは動かないとなれば、その差分の部分にバグがあるわけです。

科学実験に学ぶ検証手法

あるコードがうまく動かないとしましょう。問題がどこにあるのかを検証するには、科学の実験の手法が踏襲します。 該当の箇所に問題があるか、ないかを知りたければ、ターゲット以外が全く同じ状態で検証を行うのです。

一度にいくつもの部分に修正を入れると、どれが作用したのかわからなくなってしまいます。また、外的要因によって結果が違っているのかもしれません。そういった場合に正しく問題個所を絞り込むことができなくなってしまいます。

こういった科学実験の基礎は理学や工学系の大学に行くと学生実験という形で学びます。大学以前の学校での理科の実験なども基本的には同じですが、それほど科学的検証を厳しく問われないので印象としては薄いかもしれません。（厳しい大学だとレポートの再提出に学生は苦しむ）

オカルトなどでは、因果関係を正しく掴まないことによるものが多くあります。とくに、結果ありきでの実験のレポートは見るに堪えません。結論付けたい事柄があって、そのことに都合がよいように実験をしてはいけません。プログラムのバグの検証も、頭の中で「XXが悪いに違いない」などと強く思うと堂々巡りでなかなか解決できないところに迷い込むかもしれません。

部品単位で検品を行う

プログラムはパーツパーツで動作確認をとって組み上げる必要があります。小さなパーツが正しく動くかどうかテストすることは簡単です。しかく、組み合わさって大きな機能になると、動作確認は格段に難しい。

boolean値がひとつ増えるだけでテストケースは2倍になるのです。全部組み上げてから部品のテストを行うなどと考えてはいけません。急がば回れということです。

仕様がよくわからないといったときには、とにかくミニマムコードを書いて動かして検証しましょう。もし、理解できない動きがあるのであれば、そのときはコードを示して質問するなどすればよい。

問題の切り分けもできず、長いプログラムを掲示板に張り付けたところで、労力をかけてまで読んでくれる人は稀です。ミニマムコードにまでそぎ落としてあれば検証してくれる人はぐっと増えることでしょう。

プログラムにおける数学的帰納法の難しさ

凪瀬 — Fri, 30 Nov 2007 23:46:00 GMT

επιστημη氏の白箱試験にて簡単なプログラムを例にホワイトボックステストでは数学的帰納法の観点で境界値をピックアップしてテストケースを削減することを取り上げています。

しかし、数学の場合の数学的帰納法と違って、コンピュータにおける数学的帰納法には落とし穴があるのです。

// 引数を2倍して返す int hoge(int x) { return x * 2; }

一見すると、0で正常に動き、引数がnのとき、n+1でも成り立ちそうです。負の値のときも動きそうですから、-1,0,1でテストすれば大丈夫そうに思えますね。

しかし、0から順に初めて、1,2,3と進めていくと、ある値を超えたときにオーバーフローして値がおかしくなってしまいます。

「でも、オーバーフローするまでの範囲では大丈夫なんだろう？テストの区間をうまく区切ればいいだけさ」

では、どうやってうまく区切れていて、見落としがないことを証明できるのでしょうか？
この困難さこそが、テストケースをうまく作ることの難しさなのです。

数学的帰納法で完全なテストを行えるか？

凪瀬 — Thu, 29 Nov 2007 15:00:00 GMT

以前、完全なテストは不可能だという稿を書いたのですが、これに対して反論しているページを見つけたので考察しておきます。

反論の骨子

該当ページの文章が短いので全文引用となってしまいますが、法的な引用の要件を満たせると思うので引用します。

思うに、それは論理学でいうところの帰納法で解決できるのではなかろうか。

完全なテストは不可能だ:
さて、プログラムの話に戻ります。intの引数を2個とる場合、その組み合わせは1600京ほどになるということを先の稿で述べました。そして、バグが「ある」ことを証明する場合、バグの例をひとつ探し出せばよいのに対し、バグが「ない」ことを証明するにはこの1600京のパターンすべてを網羅して検査し、全て正常に動いたということを提示しなければなりません。

数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。というかそうでないものの方が少ないはず。

悪魔の証明、という目の付けどころは悪くないのに。まあ、ちょと前に自分でも取り上げたわけだが。

つまり、帰納法を用いることで全てを演算することなく正しさを証明できるのではないか？という主張ですね。

帰納法とは何か？

まず帰納法とはなんでしょうか。概要を知るにはwikipediaがてっとり早いので該当項目を見て見ましょう。

http://ja.wikipedia.org/wiki/%E5%B8%B0%E7%B4%8D

帰納（きのう、Induction）法とは、個別的・特殊的な事例から一般的・普遍的な規則を見出そうとする推論方法のこと。対義語は演繹法。演繹においては前提が真であれば結論も必然的に真であるが、帰納においては前提が真であるからといって結論が真であることは保証されない。

帰納法は真実を得られません。一部の事例から、全体を推論するのですが、論理の飛躍が含まれます。
例えば、intを引数にとるメソッドに対し、-1,0,1の３つの値を入れた際にうまく動いたからといって、すべての値に対して正しく動作するとは言えませんよね。

帰納法とは3つうまくいったんだから、全部の値でうまくいくはずだという推論ですから、帰納法を用いてメソッドの完全性を求めることはできません。

数学的帰納法という名の演繹法

「数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある。」と述べていることから、「帰納法」といっているのは多分、数学的帰納法のことを指しているのではないかと思われます。

さて、数学的帰納法というのは帰納法という名が付いていますが、実際には演繹法（えんえきほう）です。

http://ja.wikipedia.org/wiki/%E6%95%B0%E5%AD%A6%E7%9A%84%E5%B8%B0%E7%B4%8D%E6%B3%95

数学的帰納法（すうがくてききのうほう）とは、有限回の議論で可算無限個の対象に対する命題を証明するための数学の論法である。次のような手順で自然数全体に関する命題 P(n) (n∈N) が真であることを証明する論法である。

P(0) は真である。

任意の自然数 k に対し，P(k) が真であれば，P(k+1) も真である。

よって任意の自然数 n について P(n) は真である。

イメージとしては、2 により次々と次の命題の正しさが伝播されていくことになる。つまり、1 によりまず P(0) は正しく、P(0) と 2 により P(1) は正しく、P(1) と 2 により P(2) は正しく、以下これが果てしなく続いていく。このことによって任意の自然数 n について P(n) が正しいことが保証される。

なお、数学的「帰納法」という名前がつけられているが、数学的帰納法の解法プロセス自体は帰納法ではなく演繹法である。先に述べた、「2 により次々と次の命題の正しさが伝播されてい」った結果証明されていく様子が帰納のように見えるためつけられたにすぎない。

これは、学校で習いましたよね。
数学的帰納法はドミノ倒しに似ています。

あるドミノが倒れたら、次のドミノが倒れるようにしておく
最初のドミノを倒す

このふたつがポイントです。ドミノを倒すことで全ての数を計算するのです。
ですから、「数学でも、全ての数を計算したわけではないのに成立している定理は山ほどある」というのは多分に誤解を含んでいます。数学的帰納法に拠らない証明で成立している定理もありますが、 数学的帰納法で証明されている定理に関して言えば全てを計算しているのです。

ドミノが勝手に倒れてくれるので準備を整えたら無限のかなたまで手間無く一瞬で計算できるだけのことです。

テストに数学的帰納法を適用するには

ブラックボックステストで数学的帰納法を扱う術はありません。あるドミノが倒れたら次のドミノも倒れるという証明ができないからです。
ブラックボックステストでは実行した結果を仕様と照らし合わせて等しいかみる必要があります。実行せずに正しい答えを返すことを証明することは不可能です。

となれば、ホワイトボックステスト的な手法をとらざるを得ません。それはもはや、プログラムのコードが正しく機能することを数学的に証明を導くことに等しい重労働です。

このようなアプローチは形式的検証と呼ばれています。

このアプローチでプログラムの完全な正しさを証明しようとするのであれば、数学者を大量に雇いいれ、幾千もあるメソッドに対してそれぞれ独自の証明を人力で解いていかないといけません。複雑なメソッドの正しさを数学的に証明しようとした場合、それは世紀の難問にも等しい難度を誇ることでしょう。

指摘もとのblogの言葉を借りるならば「帰納法、という目の付けどころは悪くないのに。」といったところでしょうか。

AOPトランザクション＋キャッシュの組み合わせは同期に気をつける

凪瀬 — Sat, 06 Oct 2007 15:08:00 GMT

先日遭遇した深い落とし穴を紹介します。以下のようなシステムを開発している方は同様の問題がないかチェックしてください。

AOPでトランザクションを管理している

一部のマスタテーブルをDBから読み込んだあとシステム内でキャッシュしている

マスタメンテナンス画面などで更新があった場合にキャッシュをクリアしている

問題となるコード

Springや、SeasarといったDIコンテナなどに付随するAOPの機能を用いてトランザクション管理していると、 DBをいじる部分のメソッド内ではcommitとかrollbackとか記述する必要がありません。これは非常に便利で、人的なコーディングでのcommit漏れ、rollback漏れがないのでバグも入り込みにくく効率のよいものです。

私のやっているプロジェクトではSpringframeworkのAOPの機能を用いてトランザクション管理を行っています。

そして、システム内でよく使われ、更新頻度の低いUserテーブルは、DBアクセスのオーバーヘッドを軽減するためにシステム内でキャッシュしているのです。

/** ユーザのキャッシュ */ Map<Integer, User> cache; /** ユーザ取得処理 */ public User getUser(int userId) { synchronized (this.cache) { // キャッシュにあればキャッシュされたUserを返す if (this.cache.containsKey(userId)) { return this.cache.get(userId); } // なければDBから読み込む return this.userDao.getUser(userId); } } /** キャッシュの削除処理 */ public void clearCache(int userId) { synchronized (this.cache) { this.cache.remove(userId); } }

キャッシュの実装は上記のようなもので、内部で同期をとってあります。
そして、UserのUPDATE処理では

public void update (User user) { // UPDATE this.userDao.update(user); // キャッシュから更新対象のUserを削除 // 次回Userを取得しようとした時にキャッシュに最新のUserが読み込まれる clearCache(user.getUserId()); }

といった作りにしていたのです。このupdateメソッドに対してAOPでトランザクションがかけられるわけですね。

Commit前、キャッシュクリア後の魔

前置きが長くなりました。問題が発生するのはこのupdateの際のキャッシュのクリアの後です。

並列して走っているスレッドがあり、update後のキャッシュクリア後、しかしDBのcommitが完了する前のタイミングで getUser()してしまったのです。
すると、DBはcommitされる前ですから、更新前のUser情報が読み込まれ、キャッシュには古い情報が残り続けるというわけ。

DBのトランザクションとキャッシュクリアは不可分に行わなければならないのです。
しかし、AOPでトランザクションを管理している場合、メソッド境界を跨ぐことになるので synchronized文で容易にくくってやることができない…。

わざわざキャッシュ管理している場所だけ特殊なトランザクション処理を別途書いてAOPを適用してやる必要が出てきてしまいました。
似たようなシステム構成をしている方、潜在的なバグを孕んでいる可能性があります。早急にチェックするほうがよいでしょう。

防衛的プログラミング - Javaのセッション管理

凪瀬 — Tue, 02 Oct 2007 14:24:00 GMT

Programming SHOT BARへようこそ。今回はWebアプリケーションでのセッション管理の際の防衛的プログラミングです。

数日前にASP.NETでのセッション管理の話題がわんくま内で盛り上がっていましたが ( けろ様のページがまとめになっているのかな？)、 .NET系は詳しくないのであまり口が挟めず…。

私の理解ではJavaの場合のセッション管理と概念は同じ、しかし、実装が違うという程度のようなので本質的な問題は一緒なのではないかと捉えています(@ITの記事を参考にしました)。
とりあえず、この稿ではJavaの大規模開発でセッションを扱う場合の防衛策に注視してお送りします。

セッションに値を格納するには

以下はセッションに値を格納する簡単なサンプルプログラムです。

public class SampleServlet extends HttpServlet { /** * @see javax.servlet.http.HttpServlet#doGet(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse) */ @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { HttpSession session = request.getSession(); session.setAttribute("test", new Object()); } }

HttpServletRequestオブジェクトからセッションを表すHttpSessionオブジェクトを取得していることがわかりますね。これは、HttpServletRequestオブジェクトを参照できるあらゆる場所からセッションを操作される可能性があることを意味しています。

セッションには無秩序になんでも格納すればよいというものではありません。格納するのは使うことを想定して格納するわけです。ところが、無秩序に格納してしまうと、どこで格納したものを参照しようとしているのか、わからなくなってしまいます。格納されているデータがどうもおかしい、となれば、出所を突き止めなければなりません。しかし、誰もが自由にセッションでデータを置けるのだとしたら、誰が置いたデータなのか出所が不明になってしまうわけです。これでは困ります。

人的運用でのセッションの管理の限界

業務でシステムを作る場合、少なくともどういうキーでどこのモジュールが何を格納するのか、そして、それを参照するのはどこなのか(汎用データの場合は参照元は管理しないことが多いでしょう) といったことを書類で管理します。

しかし、書類でしか管理されていない場合、ひっそりとセッションに情報を格納しても、何かよほどの機会でもない限り、発覚しないわけです。しかも、大規模なシステム開発というのは100人以上の人が入り乱れて開発していたりしますから、
「セッションへの値の格納には書面で報告し、許可を得ること」
とお触れを出したところで行き渡らないこともあります。全体会議を開いて注意事項を述べたとしても、人の入れ替わりも多いですから、それ以後にプロジェクトに参加した人は「聞いていないよ、そんなこと」となってしまうこともあります。

人に対する啓蒙活動を無駄だとは言いませんが、確実ではないことは(残念ながら)間違いないことなのです。

プログラムで防衛を試みる

人に守らせるという根性論ではうまくいかないとなれば、プログラムで機械的にはじく方法論を考えることになります。故意にせよ、事故にせよ、管理外のセッション操作は検出して警告しないといけません。

しかし、HttpSessionオブジェクトはHttpServletRequestから取得できるわけですし、 HttpServletRequestはインターフェースで実装はサーブレットコンテナによって作られ、 Servletの引数に渡される代物なのです。

突破口はjavax.servlet.Filterにあります。
FilterはServletの処理の前に噛ませることが出来る、文字通りフィルタなのです。ここでHttpServletRequestをGoFデザインパターンのProxyパターンでセッション操作に対して警告するように細工したHttpServletRequestに差し替えればシステム全体でセッションをいじろうとした際に警告することが出来ます。

まずFilterでは

public class ReadOnlySessionFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { chain.doFilter(new HttpServletRequestProxy((HttpServletRequest) request), response); } public void init(FilterConfig config) throws ServletException { // TODO } public void destroy() { // TODO } }

といったように、chain.doFilter()の引数の時点でHttpServletRequestに細工します。 HttpServletRequestの実装は

public class HttpServletRequestProxy implements HttpServletRequest { private HttpServletRequest request; public HttpServletRequestProxy(HttpServletRequest request) { this.request = request; } /** ラップして返す */ public HttpSession getSession() { return new HttpSessionProxy(this.request.getSession()); } // 以下各メソッドをthis.request.xxx()として委譲

と細工したHttpSessionを返すようにし、HttpSessionの実装では

public class HttpSessionProxy implements HttpSession { private HttpSession session; public HttpSessionProxy(HttpSession session) { this.session = session; } public void setAttribute(String arg0, Object arg1) { throw new UnsupportedOperationException( "管理クラス以外からのセッション操作は禁じられています"); } /** 同一パッケージ内の管理クラスから設定する場合に用いる迂回路 */ void setAttributeInner(String arg0, Object arg1) { this.session.setAttribute(arg0, arg1); } // 以下各メソッドをthis.session.xxx()として委譲

といったように、UnsupportedOperationExceptionをthrowするように仕込んでおきます。このままでは、セッションになにも格納できないのでアクセスレベルをパッケージプライベートにした setAttributeInner()を作っておいて、管理クラスからのアクセスだけを受け付けるようにします。

このような工夫をすることで、セッションへのデータの格納を検出し、警告することが出来ます。

問題点

このような細工をしてしまうと、フレームワークなどで暗黙にセッションにデータを格納したりしているようなケースがあると動いてくれません。使えないケースもあると思います。

また、サンプルではざっくり省略していますがHttpServletRequestもHttpSessionもメソッド数の多いインターフェースであるため、Proxyクラスを作るのは結構大変です。また、サンプルでは省略していますが、本当は他にもオーバーライドする必要のあるメソッドがあります。

このようなクラスは開発時には意義がありますが、本番運用時には不要であるため、テストの段階で取り除いてやる必要があるでしょう。

大規模システムとなると、技術力も理解もさまざまな人が入り乱れて開発しますから、こういった防衛策を地味に重ねることがトラブルを未然に防ぎ、全体の品質を向上させ、開発効率を高めることとなります。

Objectよ、汝の出自を示せ

凪瀬 — Mon, 20 Aug 2007 12:04:00 GMT

いらっしゃいませ。
某国産の食品の品質がいろいろといわれた昨今ですが、やはり、流通路というか出自というのは重要な情報ですよね。
なお、当店の素材はできるだけ本家の厳選された素材に基づくようにしております。

スタックトレースでの追跡

デバッグの際に非常に役立つスタックトレース。活用していますか？
これはスレッドの流れを示しています。いわば流通路のようなものです。

メソッドに不正な引数が渡された場合、この流通路を遡ればどこの誰がばったもんを流したのか調査することが出来ます。犯人を見つけたらとっちめてやりましょう。

しかし、キャッシュされるオブジェクトや、staticフィールドに保持されるオブジェクトなどスレッドの流れとは一旦隔絶される場合、トレースを追いかけても犯人をつかめないことがあります。

/** Object置き場。ここに置いたのを処理する */ private Object object; /** 置き場にObjectを置く */ public void setObject(Object object) { this.object = object; } /** 置き場のデータを処理するメソッド */ public void hoge() { Object o = this.object; // 置き場にあるデータを使って処理を進める // ... }

このコードではhoge()メソッドの呼び出しに直接手渡しでオブジェクトが渡されるわけではありません。そのため、何時どこで誰がObject置き場にデータを置いたのか、スタックトレースからは追いかけることができません。

オブジェクトの出自

このスタックトレース、プログラムで扱うことができるようになっています。 Thread#getStackTrace()で対象スレッドの現時点でのスタックトレースを取得することが出来ます。
オブジェクトの生成時にこれをとっておいたらどうでしょうか？

/** インスタンス生成時のスタックトレース */ private StackTraceElement[] createLog; /** コンストラクタ */ public TraceTest() { // カレントスレッドからスタックトレースを取得 this.createLog = Thread.currentThread().getStackTrace(); }

このように、オブジェクトにスタックトレースの保管フィールドを用意し、コンストラクタの時点でスタックトレースをとっておきます。
すると、デバッグ時にオブジェクトの作られた場所が分かるという寸法です。

いかがでしょうか。これでデバッグの効率が上がると思いませんか？

環境ごとの注意点

Thread#getStackTrace()はJavaSE5.0からのサポートです。
JDK1.4の場合はExceptionをnewして生成したExceptionからgetStackTrace()してやることで同様の効果を得られます。

StackTraceElementクラスがJDK1.4からのサポートなので、JDK1.3以前の場合はExceptionをnewして printStackTrace(PrintStream)を利用し、ByteArrayOutputStreamか何かに繋げた PrintStreamを作成してそこにトレースを書き出すという手法を使います。文字列情報になってしまいますが、デバッグには十分でしょう。

なお、C#でもほぼ同等のことができるようですね。具体的なやり方は…誰かが書いてくれることを期待しましょう。