- - PR -
JDK7の情報交換
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-01-04 09:07
多少パフォーマンスが落ちてもいいなら、リフレクションAPIを応用して、メソッドの呼び出しを配列に格納することはできると思います。 例えば、NSSelectorクラスのようにinvokeする時点で、ClassからMethodを取得するようなものを作ったりとか。 | ||||
|
投稿日時: 2007-01-04 10:34
こんにちは。
ごく単純な状態遷移表であれば、”Stateパターン”で実装することができますね。 | ||||
|
投稿日時: 2007-01-04 18:06
昔、Docletを利用してAPIの関数とパラメタをXMLに出力し、生成したXMLのパラメタ要素の子要素に代表的なパラメタを記述すると、1つづつ途中で変更して実行するテストツールをAspectJで作成しましたが、最近はライブラリの開発ばかりで関数呼び出しより環境やデータ異常による分岐の方がとても大きいので、もっぱらcoverage重視のテストを作成しています。
ですが、関数表を使うならアスペクトを利用してみるとよいかもしれません。AspectJによるマルチスレッドの影響はよく知らないので、そのあたりが問題になるのなら、ソースを修正するアスペクトツールを利用する必要があるかもしれません。(XWeaverはちょっと使いにくいかもしれない) | ||||
|
投稿日時: 2007-01-05 00:01
いろいろご意見ありがとうごさいます。
比較的単純な状態遷移図であればStateパターンも考えますが、私の場合には、設計の段階でマトリクスにしてしまいますので、プログラムもマトリクスそのまんまの方が便利なもので...。単体テストもやりやすいですし、ログもとりやすいですし...。 私的には、状態遷移表のマトリクスを記述したら、自動的にスケルトンをジェネレェートしてくれて、リバースもできるようなeclipseのplug-inがどこかの誰かが作っててくれたりすると嬉しいなぁと思っていました。ないですかねぇ、そんな感じの。VC++対応の確かxjChartとかいうツールを以前ちょっとだけ評価したことがありましたが、それのeclipse版みたいなの。 | ||||
|
投稿日時: 2007-01-05 00:43
たびたびですみません。
状態遷移表のはなしからは飛んじゃうんですが... 常駐並行処理のプログラミングで、結合テストをしているときに障害が発生して、詳しく調べるために診断コード・ログ出力を追加したりすることって、結構ありがちな話じゃないですかぁ。でもプロジェクト規模がそこそこになるとMakeの手続きを通してテスト環境に入れるとすると1、2日のオーバヘッドなんて当たり前にでちゃう。 そこで以前から、必要なデータをあらかじめ一まとめにしておいて、実行時の設定により、必要なタイミングの必要な診断情報を取得できればいいのになぁ(自分の中ではプロパティバッグ方式と勝手に命名していますが)と常々思っていました。リフレクションAPIとかAspectJとかって、この辺にすごく使えそうですよね。ちょっと真剣に考えてみる気になりました。大変参考になりました。ありがとうございます。 | ||||
|
投稿日時: 2007-01-05 01:06
動いているものに対してモニタリングを行うのは
既にJMXというものがあります。(JDK5から) JDK6からは拡張されて複雑なデータ構造のMBean(MXBean)も作れるようになりました。 アスペクトには動的と静的がありますが、 動的アスペクトはクラスのロード直前にバイトコードを変更しますが、 静的アスペクトはコンパイル時にバイトコードを変更します。 ちょっと目的としているのとは違うかもしれません。 リフレクションに関しては、JMXでも内部で使われています。 ちなみに、今のバージョンのTomcatでもJMXが使われていますが、 セッション数を監視したり等、色々できますよ。 | ||||
|
投稿日時: 2007-01-05 01:41
すみません。私の表現(診断情報とかログとか)がよくなかったのだと思います。
私が言っていたのは、システム監視のことではなく、デバッグトレースのことについてです。コンソールにprintlnするようなアレです。常駐並行処理では、コンソール出力じゃ役に立ちませんから、だいたい循環管理するデバッグ出力ファイルとかに出しますよね。log4jやlogginAPIみたいなものを想像してください。 システム監視・システム管理に関しては、標準であるJMXに対応したインターフェースを(たとえ受託開発のシステムであっても最低限度は)提供していく必要はあると思います。システム全体で統合的に監視・管理できたほうがいいですからね。しかし、ここでのインターフェース・情報は公開されるものですから、またちょっとスタンスが変わってきてしまいますよね。 あと、AspectJですが、その”動的アスペクト”に対応してないんですか?(すみません。まだよく見てないもので...) それから、静的アスペクトって、Cでいうマクロみたに使えないですかね。ちょっと違いますかね。工夫すれば使えなくはなさそうですけど...(すみません。これは別のスレッドで、javaにマクロがなくて皆さん不便を感じていないかと思ったもので...) | ||||
|
投稿日時: 2007-01-05 02:24
なんか話がそれてきましたが・・・
要はテスト時にログのインタセプタを織り込んで、 本稼動時にログのインタセプタは織り込まないって感じですね。 アスペクトに向いている分野だと思います。 AspectJについては詳しくないので、お答えできませんが、 どのみちテーマとはかけ離れているので別スレッドをお勧めします。 私はマクロがなくても不便していませんが、 マクロがあると型がコンパイル時まで不定になるので、 Javaのような静的言語に向いているか微妙だと思います。 特にIDEの型解決が難しいのではないでしょうか。 ちなみに、JDK7ではマクロではありませんが、
見たいな感じの構文がサポートされる可能性もありそうです。 |