Java

AgitarのJUnitコード自動生成

かつのり — Mon, 11 Feb 2008 03:33:00 GMT

Agitarというツールがあって、これはJUnitのコードを自動生成してくれたりするツールなんですが、これまたエラい高いツールだった記憶があります。しかし、いつの間にやらウェブサービス化しているみたいで、無料で扱えるみたいです。

簡単に言うと、Agitarのサーバ上にアップしたクラスに対して、自動的にテストケースを作成してくれるみたいです。

コードの中身を見て、より高いカバレッジでテストが必ず合格するテストケースを自動生成するので、元コードがバグっていたら、そのバグを正とするテストケースが生成されます。この辺は要注意です。

詳しくはこちら。

http://www.atmarkit.co.jp/fjava/rensai3/eclipseplgn24/eclipseplgn24_1.html

久々にデッドロック＼(＾o＾)／

かつのり — Thu, 31 Jan 2008 21:38:00 GMT

久々にデッドロックというものをやってしまいました。

トランザクション開始
あるレコード更新
外部のRESTのWEBサービス呼び出し⇒＼(＾o＾)／
トランザクション終了

という処理で、WEBサービス側は、

呼ばれる
こっち側のWEBサービスで対象レコード参照⇒＼(＾o＾)／
処理完了

という感じで、なんつーか絵に描いたようなデッドロックを経験しました。トランザクション内での外部リソースの呼び出しは要注意ですね。

OpenJDKに言語機能を追加するプロジェクト

かつのり — Thu, 20 Dec 2007 02:21:00 GMT

http://www.infoq.com/jp/news/2007/12/kijaro

なかなか面白い話です。JDKに言語の機能をオープンな場で追加しましょうというプロジェクトなんですが、既に何点かのドラフトが出ています。（実際に取り込まれる可能性については微妙です）

http://kijaro.dev.java.net/

こちらで議論されているのですが、

プロパティ構文
staticメソッドの抽象化
enumの抽象化
メソッド、フィールドオブジェクトの参照構文

です。プロパティ構文というのは、.NETの世界にあるアレです。

staticメソッドの抽象化は、今まで俗に言うインスタンスメソッドではなくクラスメソッドとしてインプリメンツできるようにしようという機能です。今まではstaticメソッドの抽象化ができなかったので、汎用的なファクトリクラスあたりを作りのが難しかったのですが、これがあるとファクトリクラスの設計が変わるのではないでしょうか。

enumの抽象化についてはあまりよく知りません。最後のメソッド、フィールドオブジェクトの参照構文については、Javaの世界では手続きが面倒ながらもリフレクションという機能でメソッドオブジェクトを取得できていましたが、もっと簡単なJavadoc等で使われる構文を取り込んで、よくある関数ポインタのような使い方ができるようにしようというものです。クロージャとの相性が非常によさそうです。

こういう議論の場があって、みんなで言語仕様について語れるのはいいですね。

もうJDK7用のクロージャの利用コードが出てます。

かつのり — Wed, 19 Dec 2007 00:20:00 GMT

http://javac.info/というサイトがあるのですが、JDK7から実装される予定のクロージャの仕様検討を行っているサイトです。

JDK7からのクロージャについてはEBNFレベルではよく見ていたのですが、その構文を使った実装コードも出てきたようです。

http://javac.info/jsr166z.ztar

これは、JDK7から追加されるFork-Joinフレームワークにクロージャを取り入れた実装です。一部のコードを抜粋すると、

public static final { long, long => long } longAdder = { long x, long y => x + y };

public static final class
NaturalMinReducer<T extends Comparable<? super T>>
implements { T, T => T } {

NaturalMinReducer(Class<T> type) {}

    public T invoke(T a, T b) {
        return (a != null &&
                (b == null || a.compareTo(b) <= 0))? a : b;
    }
}

public static final class IntMinReducer implements { int, int => int } {
final { int, int => int } comparator;

    public IntMinReducer({ int, int => int } comparator) {
        this.comparator = comparator;
    }

    public int invoke(int a, int b) {
        return (comparator.invoke(a, b) <= 0)? a : b;
    }
}

という感じです。う～ん、面白いですね。ラムダ式はかなり魅力的です。

BlockingQueue

かつのり — Sun, 16 Dec 2007 02:57:00 GMT

BlockingQueueについて書かれています。。。

http://d.hatena.ne.jp/m-hiyama/20071214/1197598785

たまにはPipedInputStreamとPipedOutputStreamを思い出してあげてください・・・。

丁度非同期で追加処理を行った結果がループできるイテレータが欲しかったので、BlockingQueueで実装してみました。

http://herringroe.googlecode.com/svn/trunk/herringroe-sandbox/src/main/java/jp/herringroe/commons/util/AsyncIterable.java

ポイントとしては非同期追加処理の終了通知を割り込みで行っている部分です。BlockingQueueは終わりという考え方がないので、いつまでも待ち続けるんですね。そのために大元のスレッドが取得の為にブロッキングしている状態に対して割り込んでやる必要があるのです。

もちろん割り込まなければ実現できない問題ではありません。終了を示すオブジェクトを返してもよいです。サンプルコードを書くとこんな感じで使えます。

Task<String> task = new Task<String>() { public void process(Queue<String> queue) { queue.offer("aaa"); queue.offer(null); queue.offer("aaa"); queue.offer("aaa"); } }; for (String str : AsyncIterable.iterable(task)) { System.out.println(str); }

上記コードのTaskオブジェクトのprocessメソッドはAcyncIterableの中で別スレッドで動きます。結構便利ではないでしょうか。

Tomcatの仕様が変わってる・・・

かつのり — Thu, 29 Nov 2007 02:05:00 GMT

今までTomcatの5.5.23で開発していたのですが、Tomcatの5.5.25にバージョンアップしたら動かない・・・。お客さんにリビジョン違いで動作しないのは、アプリのバグです。と言い切ってしまったので調査しました。

今までずっと放置されていた、<jsp:include>でファイルが存在しない場合に何もしないバグ？に対処したらしいです。リリースノートはキチンと読まないとダメですね。今までファイルが存在しない場合に何も行われない事に期待したコードだったので、これは致命的でした。

Tomcatは常にコードもセットで落とすようにしているので該当箇所(org.apache.jasper.servlet.JspServlet)を見ると、やはりエラーの処理が追加されていました。%CATALINA_HOME%common/classesに5.5.23のクラスを入れると問題なく動くのですが、そもそもJSPの仕様として正しいのかを調査すると、ファイルが存在しない場合の挙動が明記されていないっぽいのです。・・・コンテナ依存かよ・・・。

結局は、ひとまず5.5.23のクラスを抜き出してパッチとして5.5.25に入れる事に。そして暇を見て空っぽのインクルード対象のファイルを作成することで落ち着きそうです。

いやぁ・・・たまにこういう罠があるのですね。重要なのは、

オープンソースならAPサーバ、フレームワーク等のコードくらいは読む
リリースノートを読む
公式の仕様書を読む

「何かよくわかんないけど、うまく動かないっす・・・やっぱオープンソースはダメっすね。」とか安易に言っちゃいけません。

Javaとデータベースの相性

かつのり — Thu, 22 Nov 2007 00:38:00 GMT

凪瀬さんのエントリに触発されました。

http://blogs.wankuma.com/nagise/archive/2007/11/20/109498.aspx

Javaをやっていると、データベース操作がスッキリしません。何故なのでしょうか。

まずJavaは基本的にSQLの記述に向いていません。原因は文字列。ヒアドキュメントや、マルチラインストリングがサポートされていないので、気持ちの悪い文字列連結の繰り返しになります。

ヒアドキュメントが使えると、

String sql = <<<SQL select * from xxxx where xxxx = ? and yyyy = ? SQL;

というような感じで書けます。以下は一般的な方法です。

StringBuilder buf = new StringBuilder(); buf.append("select "); buf.append(" * "); buf.append("from "); buf.append(" xxxx "); buf.append("where "); buf.append(" xxxx = ? and "); buf.append(" yyyy = ?"); String sql = buf.toString();

私はSQLファイルを置いておいて、クラスからロードする手法か、StringWriterをラップしたPrintWriteのインスタンスを作ってSQLを生成します。SQL文の追加のたびに、意図的に空白を追加する必要はありません。

StringWriter sw = new StringWriter(); PrintWriter buf = new PrintWriter(sw); buf.println("select"); buf.println(" *"); buf.println("from"); buf.println(" xxxx"); buf.println("where"); buf.println(" xxxx = ? and"); buf.println(" yyyy = ?"); String sql = sw.toString();

どちらにせよ気持ちの悪いコードです。この辺が解決できると、コード内にSQLを書くモチベーションも上がるのではないでしょうか。

次のエントリでは解決法の前に、オブジェクトとレコードのマッピングについて考察してみます。

文字判定メモ

かつのり — Sat, 27 Oct 2007 14:36:00 GMT

個人用メモ。

携帯の絵文字が入力されたときの判定方法。3キャリアの絵文字は全てUnicodeのPrivate Use Areaとなるため、Private Use Areaであるかを判断するだけでOK。

String input = ....; for(char c : input.toCharArray()){ if(Character.UnicodeBlock.of(c) == Caracter.UnicodeBlock.PRIVATE_USE_AREA){ System.out.println("絵文字～"); } }

厳密にはキャリアごとに絵文字の領域が違う。auとSoftbankでは一部同じ領域を利用している。Private Use Areaであれば絵文字が含まれると判定するならキャリア判別は不要。

サロゲートペアが含まれているかの判定方法。

文字列のコードポイントカウントとレングスが同一なら含まれていないと判定してもよさそう。（要検証）

String input = ....; if(input.codePointCount() != input.length()){ System.out.println("さろ☆げぇと"); }

“安全”のためにTomcatを理解し、構築し、動作させる　その２

かつのり — Sun, 14 Oct 2007 13:47:00 GMT

http://blogs.wankuma.com/kacchan6/archive/2007/10/14/101938.aspx

取り合えず外向けのアプリを作るなら、これだけは必要って話をしようかなと。

カスタムエラー画面を作成
標準のレルムを外す
マネージャアプリの類を外す
サンプルアプリの類を外す

カスタムエラー画面を作成するのはバージョン情報を漏らさないようにするためです。特定バージョン向けの脆弱性が出た場合にも、バージョンが外部から分からなければ、速攻で攻撃対象にはなりにくいので、穴を塞ぐ時間稼ぎにはなります。

Tomcatを知っている場合に初期パスワードがバレバレなので、標準のレルムを外しておいた方が無難です。当然ユーザやパスワードを変えてしまえば問題ないですが、殆どアプリを作るうえでユーザ管理なんてレルムに任せる事は少ないと思います。

マネージャアプリの類はかなり危険です。パスワード間違いによるロック機能なんてないので、ブルートフォースで侵入された場合、Tomcatがrootで動いていたらサーバを捨てる事になるでしょう。rootじゃなければ、アプリを勝手に追加されたりする程度ですが、それでもかなり危険です。

“安全”のためにTomcatを理解し、構築し、動作させる

かつのり — Sun, 14 Oct 2007 01:15:00 GMT

http://www.atmarkit.co.jp/fjava/rensai4/safetomcat_01/safetomcat_01_1.html

う～ん、安全の為ならまず先に「マネージャアプリ」の類とか「サンプルアプリ」の類を殺さないかい？

解説ではTomcat6.0.14で書いているけど、6.0.13まではjsp-examplesに脆弱性もあるし、そのバージョンを記事を見ながらインストールする人もいると思うんだけど・・・