WhiteDog@Blog

LZ77によるテキスト圧縮

2013-05-19T17:01:00.001+09:00

ちょこちょこと改良を続けているTrie4Jでの話。

　LOUDSによるTrieが実装できたことで、木構造を保持するのに必要なメモリは大幅に削減されました。そうなると今度は、TAIL配列の大きさが気になってきます。最新のTailLOUDSTrieの各構成要素をファイルに書きだしてサイズをみてみると、こんな感じ。

	サイズ(KB)	説明
木構造(LOUDS)	756.8	Trie木構造をLOUDSで表現したもの
終端フラグ	189.3	木の各ノードが文字列の終端となるかどうかを表すフラグ
ラベル配列	3,054.9	木の各ノードに対応するラベル
TAILIndex配列	6,053.9	木の各ノードに対応する、TAIL配列へのインデックス
TAIL配列	9,302.8	全ノードのTAILを繋いだ文字列
合計	19,329.6

※元データは2012年2月20日のWikipedia日本語タイトル(jawiki-20120220-all-titles-in-ns0.gz)。

　木は十分に小さくなり、ラベル配列以降の文字関連データで95%以上を占める状態になっています。その中でも一番容量を食っているTAIL配列をターゲットに、圧縮方法を考えます。(ちなみにTAILIndex配列は、完備辞書により大幅に圧縮することが可能で、既にTrie4Jで実装していますが、これはまたの機会に)

　いろいろと圧縮方法を調べてみると、少し前に買ってた書籍、「高速文字列解析の世界」で解説されているLZ-Endという手法が良さそうです。

　LZ-Endは、その論文のタイトル「LZ77-like Compression with Fast Random Access」からもわかるように、LZ77をベースに、高速にランダムアクセス出来るよう拡張されたアルゴリズムです。少々複雑なので、まずはベースとなったLZ77を見てみます(LZ77も同書籍に説明があります)。

　LZ77では、文字列中の同じパターンを見つけ、より後に表れるものを過去のパターンを参照する情報に置き換えることで、圧縮を行います。具体的には、先頭から1文字ずつ見ていき、一致が無い場合は(-1, 0, 不一致文字)、あった場合は一致する文字数を調べて(先頭位置, 文字数, 不一致文字)を出力します(-1, 0の部分は、不一致を表す値であれば他のものでも構いません)。例えば

hello shallow

　という文字列があった場合の処理と出力結果は、以下のようになります。

処理番号	処理内容	出力
1	'h'は以前に現れないので、一致しない。	(-1, 0, 'h')
2	'e'は以前に現れないので、一致しない。	(-1, 0, 'e')
3	'l'は以前に現れないので、一致しない。	(-1, 0, 'l')
4	'l'は元文字列の2番目に現れ、1文字だけ一致し、次の'o'は一致しない。	(2, 1, 'o')
5	' 'は以前に現れないので、一致しない。	(-1, 0, ' ')
6	's'は以前に現れないので、一致しない。	(-1, 0, 's')
7	'h'は元文字列の0番目現れ、1文字だけ一致し、次の'a'は一致しない。	(0, 1, 'a')
8	'l'は元文字列の2番目に現れ、さらに2文字一致し、次の'w'は一致しない。	(2, 3, 'w')

　上記の処理番号と、元の文字列の対応は次の通り。処理によって圧縮された部分を赤字にしています。

1	2	3	4	5	6	7	8
h	e	l	lo		s	ha	llow

　処理の結果、(位置, 文字数, 不一致文字)の3つ組は8個出力されたことになります。それぞれ2byteとしても、3*8*2で48byte、元の文字列は13文字で、1文字2byteとすると26byteです。これからわかるように、LZ77は同じパターンがある程度現れないと、効率よく圧縮できません。ただし長いテキストデータにはある程度同じパターンが出てくるものが多く、一定の圧縮効果は期待できます。

　また、大規模なテキストを考えると、一致を先頭から順に探していては、膨大な時間がかかってしまいます。そのため構築方法に工夫が必要ですが、一般的には

一致を検索するために遡る文字数を制限する
文字の出現位置をハッシュで保持する

　という方法がとられます。
　これらの対応を行い、上記TrieのTAIL配列(9.3MB)に対してLZ77を行なってみると、約85%に圧縮されました。但しTAIL配列は既に先頭一致で重複を省いた後の文字列なので、一般的にはもっと小さくなります。実際、Trieに格納する前のWikipedia日本語タイトル約1千万文字に対して適用すると、約70%になりました。
　コードは下記を参照して下さい。
　LZ77はシンプルながら強力なアルゴリズムで、その派生がたくさんあります。一般的に使われるのはLZSSという拡張のようで、これは常に3つ組を出力するのではなく、一致する場合は(true, 先頭位置, 文字数)、一致しない場合は(false, 不一致文字)を出力する事により、さらにムダを省くものとなっています。しかしこれもランダムアクセスが難しいため、Trie4JではLZSSをさらに拡張するか、LZ-Endを使うかのどちらかにしようと考えています。

クラス	build(ms)	contains(ms)	size(MB)
java.util.HashSet	417	453	160.4
java.util.TreeSet	402	261	160.2
PatriciaTrie	442	244	104.6
TailPatriciaTrie(SuffixTrieTail)	1,220	271	100.8
TailPatriciaTrie(ConcatTail)	517	241	86.0
MultilayerPatriciaTrie	704	386	91.8
MultilayerPatriciaTrie(packed)	2,822	866	82.9
DoubleArray	471	106	48.5
TailDoubleArray(SuffixTrieTail)	3,078	175	37.3
TailDoubleArray(ConcatTail)	2,597	157	42.0
LOUDSTrie(SuffixTrieTail)	777	508	18.1
LOUDSTrie(ConcatTail)	234	483	22.9

LOUDSTrie実装してみた

2012-08-25T00:33:00.002+09:00

よく考えたらblogに載せてなかった(TwitterやGoogle+でつぶやいて載せた気になってた・・)ので、改めて。

LOUDSはLevel-order Unary Degree Sequenceの略。詳しくは書籍「日本語入力を支える技術」(amazon)や下記サイトを参照してください。

要は木構造を01のビット列で表そうというデータ構造で、遅いけどかなり小さく圧縮できる。ただでさえJavaではオブジェクトがメモリを食う(何もフィールド無くてもポインタ2個分消費する)ので、木構造がビット列で表現できれば、絶大なサイズ削減効果があります。

既に構築済みのトライからLOUDS Trieを構築するのは結構簡単で、幅優先でトライを辿り、子の数だけ1を追加、最後に0を追加というのを繰り返すだけ。trie4jではこんな感じに実装してます。

https://github.com/takawitter/trie4j/blob/master/trie4j/src/org/trie4j/louds/LOUDSTrie.java#L53

構築済みのトライを辿るには、ルートから、

左端の子ノードの位置を求める(簡潔ビット配列のselect0操作)
右端の子ノードの位置を求める(簡潔ビット配列のselect0操作)
左端の子ノードのIDを求める(簡潔ビット配列のrank1操作)
子ノードから適切なラベルを持つものを探す
子ノードのTAIL配列(2番目以降のラベル文字列)を得て検索文字列と比較

という感じで子ノードの検索、文字列比較を行っていく。これを高速に行うのが結構面倒で、select0やrank1をどう高速化するか、ビット配列の実装が肝になります。

trie4jでは、select0、rank1共にキャッシュを作って高速化してます。また、上記2の処理専用にnext0という操作を簡潔ビット配列クラス(SuccinctBitVector)に追加してます。そこらへんの工夫により、127万件の要素を照合するのに500ms程度と、まずまずの速度を確保してます(もちろんC++で実装されたライブラリに比べれば遅いだろうけど)。

trie4jの実装はこちら https://github.com/takawitter/trie4jからどうぞ。BuildHive使って、最新のスナップショットtrie4j-SNAPSHOT.jarも常にダウンロードできる状態にしてあります。

各種トライの速度比較

2012-06-15T00:54:00.001+09:00

6/17 GCの影響をできるだけ排除するように実装し、測り直しました。

LOUDSTrieの実装が落ち着いてきたので、パトリシアトライ、ダブルアレイ、LOUDSトライの構築、contains速度を測ってみました。

何回か測ってみたけど、だいたいこんな感じ。

	構築(ms)	contains(ms)
java.util.HashSet	1,042	816
PatriciaTrie(UTF-16 char[])	891	662
MultilayerPatriciaTrie(多層トライ)	3,538	1,354
TailCompactionDoubleArray	5,082	858
OptimizedTailCompactionDoubleArray	5,760	1,022
LOUDSTrie	922	1,025

CPUはCore i7 2.5GHz。データはWikipedia日本語タイトル127万件。パトリシアトライの実装はここ、ダブルアレイの実装はここを参照。DoubleArray2つとLOUDSTrieはPatriciaTrieを使って構築してるので、実際の構築時間はPatriciaTrieの分も必要です。

意外とLOUDSTrieが構築、検索共に頑張ってる印象。というかDoubleArrayってもっと速いんじゃなかったっけ。実装が悪いのかも知れませんが。

実装はTrie4J(GitHub)にて公開してます。

Wikipedia英語タイトルも格納してみた

2012-05-16T22:07:00.002+09:00

Wikipedia英語版のタイトル一覧(2012/4/3版。9,310,564エントリ)も格納して、サイズ測ってみました。

実装	配列要素数(base/check等)	TAIL配列要素数	全体サイズ
OptimizedTailCompactionDoubleArray	12,710,311	15,699,525	162,867,250

各種トライの性能を比較した記事「2011-01-10 marisa-trie 強いな」と比較してみると、エントリ数が1.5倍弱になってることを考慮して、darts-cloneに近いメモリ効率をたたき出してると思う。ただdarts-cloneはTAILをDAWG(Directed Acyclic Word Graph)で保持してるようなので、今のトライ使ったTAIL圧縮だと勝てないかも知れない。あと文字をcharで保持してたり、違いはいろいろ。まぁこっちはJavaなので既に速度的にはだいぶ水開けられてるし(Corei72.5GHzで24秒程度)、元よりあまり有効な比較にはならないかも知れない。構築途中で1.3GBくらいメモリ消費するしねー。

ダブルアレイのサイズ比較

2012-05-16T21:48:00.000+09:00

今勉強＆実装してるダブルアレイのサイズを測ってみました。詳しい話はまた今度(というつつパトリシアトライの解説もまだ途中だけど・・・)。

データはパトリシアトライと同じく、Wikipedia日本語タイトルの127万エントリ。文字列は全てcharで保持してます。また、予めパトリシアトライを構築し、それをもとにダブルアレイを構築してます。

以下の表にまとめます。

実装	配列要素数(base/check等)	TAIL配列要素数	全体サイズ
DoubleArray^*1	5,668,704	0	48,547,151
TailDoubleArray^*2	1,679,616	4,651,339(capacity: 4,718,590)	31,947,268
TailCompactionDoubleArray^*3	1,679,616	1,797,866(capacity: 2,359,294)	27,226,058
OptimizedTailCompactionDoubleArray^*4	1,519,679	1,797,866	21,177,535

*1 - シンプルなダブルアレイ実装。空き要素の位置を記録して構築高速化、孫ノードの多い子ノードを先に登録してメモリ利用効率向上、TAIL無し。
*2 - TAILあり。
*3 - 接尾辞トライによるTAIL圧縮。
*4 - 構築終了時に配列サイズをtrim。checkの要素をintではなくcharにする。

パトリシアトライの時に苦労していたのが嘘のように、シンプルな実装でいきなり48MBを叩きだしてます。前回Javaではオブジェクト数大事、と連呼してましたが、トライを保持する方法がノードオブジェクトをポインタでつなぐ方法から、int配列2つに変わったことで、TAIL圧縮すらしてないのに約34MB減りました。

結論: やっぱりオブジェクト数大事

さらにTAIL配列、TAIL配列圧縮等工夫していくことで、最終的に21MBまで小さくなっています。これ以上は、ダブルアレイの仕組みそのものを変えないと大幅な圧縮は期待できず、行き着く先は、トライの保持をビットベクタで行うLOUDS(Level Order Unary Degree Sequence。参考)です。なので今後はLOUDSを勉強&実装してく予定です。

ダブルアレイの実装について少し。最初のDoubleArrayクラスでは、教科書通りの実装(こことか参照)に加えて、少し効率化を図ってます。一つは構築速度の効率化として行なっている、空き要素位置の保持です。これは最初の空き要素位置を保持する変数を1個儲け、2番目以降の空き要素位置はcheck配列内に保持してます。ただし真面目にやると大変(時間がかかる)なので、実際見に行って空き要素ではなければ、そこから1つずつ空き要素を探すようにしています。もう一つは孫ノードの多い子ノードを先に登録することで充填率が上がり、結果配列のサイズが小さくなります。これはまぁデータ依存なところはありますが。

TailDoubleArrayクラスは、DoubleArrayにTAIL配列(ここのMinimal Prefix Double-Arrayあたり参照)を導入したものです。一つしか子持たないノードが続く区間は、ラベルを文字配列内にコピーすることで、メモリ利用効率を上げます。

TailCompcationDoubleArrayクラスは、TAIL配列を可能な限り共有することで、さらに効率を上げます。"world"がTAILに格納されている状態で"javaworld"を格納する場合に"world\0java\1(0)"というように、既に接尾辞の一部が格納されている場合はそれを再利用するという工夫も行なってます。これは、多層トライで使ったテクニックを応用して、TAILを逆順に格納したトライをつくることで実現しています。このあたりはまた別途詳しく書く予定。

OptimizedTailCompactionDoubleArrayクラスは、構築終了時にbase配列やcheck配列の末尾にある使用していない領域を縮小したり、TAIL配列(中身はStringBuilder)をtrimしたりしてます。また、check配列をintではなくcharにしています。文字の種類が32,767を超えると格納できなくなりますし、次の空き要素までの距離が32,768を超えても格納できなくなります。現実的にはどちらもまず起こらない(Wikipedia日本語タイトルでも、文字種は7,564)ので、実用上問題ないんじゃないかと思います(でも念のため別クラスとして実装)。

実装は今までどおり、GitHubで公開してます。

パトリシアトライのサイズ比較

2012-04-19T23:30:00.001+09:00

　記事が前後しますが。気になったのでちょっと調べてみました。トライの内部形式をchar[]からbyte[]にすることでどれくらいインパクトがあるのか。byte[]にする際、UTF-8、Shift-JIS、EUC、JIS(ISO2022JP)でどのような違いがあるのか。

以下の表にまとめます。

	トライのノード		文字配列数
エンコーディング(内部形式)	数	サイズ	数	サイズ	全体サイズ
ISO-2022-JP(byte[])	1,763,967	58,210,911	1,764,142	41,189,910	123,904,937
UTF-8(byte[])	1,736,910	57,318,030	1,737,083	40,404,315	123,095,316
Shift_JIS(byte[])	1,639,064	54,089,112	1,639,229	35,103,790	112,335,651
EUC_JP(byte[])	1,633,865	53,917,545	1,634,031	35,089,059	112,013,060
UTF-16(char[])	1,513,469	48,431,008	1,515,346	35,043,030	103,472,496
UTF-16(char[])+フィールド最適化^(*1)	1,513,469^(*3)	39,664,136^(*4)	1,515,338	34,688,312	91,774,563
UTF-16(char[])+フィールド最適化^(1)+多層トライ^(2)	1,995,303^(*3)	55,082,824^(*4)	483,714^(*5)	10,345,546^(*5)	82,870,660

*1 - 子ノードを持たない/1つだけ/2つ以上、終端である/ないの組み合わせでそれぞれ最適なフィールドを持つノードクラスを使用する。
*2 - ラベルを逆順に持つ圧縮用トライを用意(参考: 多層トライの実験結果 - やた＠はてな日記)。本来のトライのノードもその圧縮用トライのノードをフィールドに持つものを使用。
*3 - 全ノードの合計数。
*4 - 全ノードの合計サイズ。
*5 - 文字配列は圧縮用トライ内のもの。本来のトライには文字配列を持たない。

いずれもWikipedia日本語タイトル127.3万件を格納した結果です。フィールド最適化+多層トライのデータでは、圧縮用トライのノードや文字配列のサイズも加算されています。

こうして見てみると、多層トライがいかに圧縮率が高いかと、オブジェクト数の増減がいかにインパクトがあるかがわかります。せっかく多層トライで圧縮したメモリサイズ(24MB)も、ノードオブジェクト数の増加でその効果は半減しています。

結論: Javaではオブジェクト数大事

多層トライの実装はGitHubで公開してます。org.trie4j.trie.patricia.multilayer.MultilayerPatriciaTrieがフィールド最適化と多層トライの実装で、全タイトル挿入後のデータ、挿入してからpack(), morePack()を呼び出した後のデータが表の下2つです。packで多層トライでの圧縮、morePackで多層トライのノードのフィールド最適化を行います(morePack遅いです)。

下記にVisualVMでの主要なオブジェクトのスナップショットを。まずはUTF-16のフィールド最適化のみ。

次にフィールド最適化+多層トライ(もフィールド最適化)。

サイズをオブジェクト数で割るとわかるけど、1オブジェクトで24とか32バイト消費してます。フィールド最適化を行わない場合、40バイト消費することもあります(64bit環境で。32bitなら半分になります。)

結論: Javaではオブジェクト数大事(2回目)

しかしこの画像の小ささ何とかならんかな。

Trie4J - Java Patricia Trie Implementation

2012-04-13T03:11:00.002+09:00

ちょこちょことまとめているパトリシアトライのJava実装ですが、現状のソースをGitHubにあげました。

https://github.com/takawitter/trie4j

記事では簡単のためラベルをString, 子ノードをList<String>で管理しているものを紹介していますが、この実装では

ラベルをchar[]、子ノードをNode[]で管理する、org.trie4j.patricia.simple.PatriciaTrie
ノードの状態(終端かどうか、子ノードを持つかどうかなど)に応じてクラスを変更し、かつ多層トライによるサイズ圧縮に対応する、org.trie4j.patricia.multilayer.MultilayerPatriciaTrie

の2つが含まれています(もう一つありますが、あまり効果無いのでそのうち消します)。詳しい解説はまた後ほど(predictive search書けてから)。

JavaでPatriciaTrieで各種検索

2012-04-13T02:30:00.001+09:00

前回からの続きで、今回は検索メソッドを実装してみます。実装するのはこの2つ。

common prefix search
predictive search

common prefix searchは、クエリ"東京国際フォーラム"が与えられた時に、"東"、"東京"、"東京国"、"東京国際フォーラム"をトライから列挙するという検索です(実際これらの単語はWikipedia日本語版にあります)。

上図で赤枠で示したノードをたどりながら、終端ノードを列挙していく処理になります。先頭からノードをたどり、ノードのラベルとクエリを比較し、ノードのラベルを比較し終えたら、終端ノードであれば列挙、そして子ノードから残りのクエリの比較を行う候補を探し、そのノードに対しても同じ処理をしていきます。一方向に辿っていくだけなので再帰は必要なく、単純なループで実現できます。コードを下記に示します。

public Iterable<String> commonPrefixSearch(String query) {
 List<String> ret = new ArrayList<String>(); // 結果配列
 int cur = 0; // query内の照合位置
 Node node = root;
 while(node != null){
  String letters = node.getLetters();
  if(letters.length() > (query.length() - cur)) return ret; // 残りの文字列よりノードのラベルのほうが長ければマッチしないので終了
  for(int i = 0; i < letters.length(); i++){
   if(letters.charAt(i) != query.charAt(cur + i)) return ret;
  }
  if(node.isTerminated()){
   ret.add(query.substring(0 , cur + letters.length()));
  }
  cur += letters.length();
  if(query.length() == cur) return ret;
  node = node.getChild(query.charAt(cur));
 }
 return ret;
}

単純なwhileループで、着目するノード(変数node)を書き換えながら処理を行なっています。
predictive searchは、指定された文字列(prefix)を前方一致検索します。例えば"東京国"が指定されれば、"東京国"、"東京国税局"、"東京国際フォーラム"、"東京国際マラソン"が列挙されます。

上図赤枠のノードが列挙対象になります。まず指定されたprefixを含むノードを探し、見つかったノード以降のノードを全て列挙します。この列挙は部分木全部が対象になるので、再帰で実装するのが楽です(再帰が嫌な場合はQueue使ってもOK)。コードはこんな感じ。

/**
 * 部分木の列挙をする再帰関数。
 */
private static void enumLetters(Node node, String prefix, List<String> letters){
 List<node> children = node.getChildren();
 if(children == null) return;
 for(Node child : children){
  String text = prefix + child.getLetters();
  if(child.isTerminated()) letters.add(text);
  enumLetters(child, text, letters);
 }
}

public Iterable<String> predictiveSearch(String prefix) {
 char[] prefixChars = prefix.toCharArray();
 int cur = 0; // prefixChars内の照合位置
 Node node = root;
 while(node != null){
  String letters = node.getLetters();
  int n = Math.min(letters.length(), prefixChars.length - cur); // 共通部分の比較のためnは短い方に合わせる。
  for(int i = 0; i < n; i++){
   if(letters.charAt(i) != prefixChars[cur + i]){
    return Collections.emptyList();
   }
  }
  cur += n;
  if(prefixChars.length == cur){ // prefixCharsの比較が終われば、あとは部分木の列挙
   List<String> ret = new ArrayList<String>();
   prefix += letters.substring(n);
   if(node.isTerminated()) ret.add(prefix);
   enumLetters(node, prefix, ret);
   return ret;
  }
  // 比較がまだ終わって無ければ、子ノードを探して検索を継続
  node = node.getChild(prefixChars[cur]);
 }
 return Collections.emptyList();
}

JavaでPatriciaTrieを実装してみた

2012-03-15T02:06:00.003+09:00

書籍「日本語入力を支える技術」を読んでテンション上がったので、Javaでパトリシアトライを実装してみました(本当はビットベクタを実装したかったけどとりあえずダブル配列からやろうと思ってそれでも挫折してPatriciaTrieから入門した次第)。また、このエントリで紹介するコードはパトリシアトライの説明用で、全然最適化が行われていないので、メモリ効率も速度も良くないです。そのあたりを最適化したコードは、別のエントリで紹介する予定です。

(↓※アソシエイトIDあり)

ちなみにPatriciaはPractical Algorithm to Retrieve Information Coded in Alphanumericの略らしい(参考: wikipedia:基数木)。構造は至ってシンプルで、いろいろと実装例があります。

wikipediaのパトリシアトライの説明から図を借りると、その構造はこんな感じ:

ちょっとわかりにくいので、形を変えてみると:

空間効率的には、上図右側の各文字列の灰色で示した部分が他の文字列と共有されるので、かなりデータ量は小さくて済みます(wikipedia日本語タイトルデータで50%程度の効率化)。また、検索効率は、検索したい文字列を先頭から順に探して行くだけなので、最悪O(k)で済みます(kは文字列長)。実際は子ノードの探索方法によっては検索速度に影響が出るけど、それはまた後で。

構造がわかったところで、それを表現するクラスを定義します。

public class Node{
 // コンストラクタ、getter、setterは割愛
 private String letters;
 private List<node> children;
 private boolean terminated;
}

各ノードで保持する文字列は変数lettersに、子ノードは変数childrenに格納します。加えて、そのノードで文字列が終わっているかどうかを保持する変数terminatedを設けます。これは、例えば上図の文字列に加え、"rom"や"rubic"が加わった場合、ツリーの途中で文字列が終わることになるので、それに対応するため。上図に、文字列の終端という概念を加えて、あとツリーの途中で文字列が終わるケースを示すために"rom"と"rubic"も挿入されたとして、終端のノード(terminated==true)を太枠で表すと、下図のようになります。

終端については、終端文字列を設けて('$'とか)、それを終端となるノードにぶら下げるのが一般的のようなんですが、コードをシンプルにしたかったので、上記実装にしました(実際はいくつか工夫の余地はあり、今できるだけメモリを使わない方法をトライ中なんですが、それは完成した後に詳しく書く予定)。

さて、まずはある文字列がトライに含まれるかどうかを判定する、containsメソッドを実装してみます。考え方としては、

自ノードに文字列が設定されている場合、検索文字列との比較を行う。
自ノードの文字列だけでは比較が終わらない場合、子ノードを探す。
子ノードが見つかった場合、子ノードに対して同じ操作を行う

という感じで、検索対象文字列の先頭から、ノード内の文字列との比較を行い、どんどん子ノードに降りて行きます。コードは下記。

boolean contains(String word){
 int rest = word.length();
 int n = letters.length();
 if(n > rest) return false; // 自ノードの文字列のほうが長ければ比較失敗。
 for(int i = 0; i < n; i++){
  if(letters.charAt(i) != word.charAt(i)) return false;
 }
 if(n == rest) return terminated; // 文字列が同じであれば、終端かどうかを返す。
 word = word.substring(n); // 比較済み文字列を捨てる。
 if(children != null){
  char c = word.charAt(0); // 子ノードを探す。(*1)
  for(Node n : children){
   if(n.letters.charAt(0) == c){
    return n.contains(word); // 見つかれば、containsを呼び出す。
   }
  }
 }
 return false;
}

自ノードの文字列(letters)、子ノード(children)の順で処理を行なっています。子ノードの検索(*1)は線形探索していて、当然遅いので、実用で使うには、頻度順に並べるとか、childrenはソートしておいて2分探索を使うとか、ハッシュを使うとかする必要がありますが、今は割愛。データ量が膨大になる場合は、各ノードでハッシュを持つとメモリ消費が問題になる可能性があるので、2分探索か頻度順が現実的かと思います(そのぶん構築コストは高いけど)。実際wikipediaの日本語タイトルを挿入してみると、線形探索と2分探索では、処理にかかる時間の桁が違いました(50万件の検索で線形探索1762ms, 2分探索201ms)。

ちなみに2分探索だと、コードは下記のようになります。

boolean contains(String word){
 int rest = word.length();
 int n = letters.length();
 if(n > rest) return false; // 自ノードの文字列のほうが長ければ比較失敗。
 for(int i = 0; i < n; i++){
  if(letters.charAt(i) != word.charAt(i)) return false;
 }
 if(n == rest) return terminated; // 文字列が同じであれば、終端かどうかを返す。
 word = word.substring(n); // 比較済み文字列を捨てる。
 if(children != null){
  char c = word.charAt(0); // 2分探索で子ノードを探す
  int end = children.size();
  int start = 0;
  while(start < end){
   int i = (start + end) / 2;
   Node child = children.get(i);
   int d = c - child.getLetters().charAt(0);
   if(d == 0){
    return child.contains(word);
   }
   if(d < 0){
    end = i;
   } else if(start == i){
    break;
   } else{
    start = i;
   }
  }
 }
 return false;
}

次に要素の挿入です。おおまかに以下の流れで実装しました。

ノード内の文字列(thisLetters)か比較対象の文字列(letters)の短い方の文字数分比較
全て比較成功
1. thisLettersとlettersの長さが同じであれば、ノードを終端にして(terminated = true)終了(a)
2. thisLettersの方が長ければ、ノードを分割して終了(b)
3. lettersの方が長ければ、比較済み文字列を捨てる
4. 新しいlettersの先頭文字とマッチする先頭文字を持つ子ノードを探す
5. 存在すれば、その子ノードに対してinsertChildを呼び出して終了(c)
6. 存在しなければ、新しい子ノードを作成して追加し終了(d)
途中で比較が止まった場合、その位置でノードを分割し、lettersの残りも子ノードとして追加する。(e)

コードは下記のようになります。

public void insertChild(String letters){
   int n = Math.min(letters.length(), this.letters.length());
   int i = 0;
   while(i < n && (letters.charAt(i) == this.letters.charAt(i))) i++;
   if(i == n){
    if(letters.length() == this.letters.length()){
     terminated = true; // (a)
     return;
    }
    if(letters.length() < this.letters.length()){
     Node node = new Node( // (b)
       this.letters.substring(letters.length())
       , this.children, this.terminated);
     this.letters = letters;
     this.children = new ArrayList<Node>(1);
     this.children.add(node);
     ((ArrayList<Node>)this.children).trimToSize();
     this.terminated = true;
     return;
    }
    letters = letters.substring(i);
    int index = 0;
    for(Node child : children){
     int c = letters.charAt(0) - child.letters.charAt(0);
     if(c < 0) break;
     if(c == 0){
      child.insertChild(letters); // (c)
      return;
     }
     index++;
    }
    this.children.add(index, new Node(letters)); // (d)
    ((ArrayList<Node>)this.children).trimToSize();
    return;
   }
   String newLetter1 = this.letters.substring(0, i); // (e)
   String newLetter2 = this.letters.substring(i);
   String newLetter3 = letters.substring(i);
   List<Node> newChildren = new ArrayList<Node>(2);
   if(newLetter2.charAt(0) < newLetter3.charAt(0)){
    newChildren.add(new Node(newLetter2, this.children, this.terminated));
    newChildren.add(new Node(newLetter3));
   } else{
    newChildren.add(new Node(newLetter3));
    newChildren.add(new Node(newLetter2, this.children, this.terminated));
   }
   this.letters = newLetter1;
   this.terminated = false;
   this.children = newChildren;
  }

なお、子ノードは全て昇順でソートされるようにして、探索は線型探索を使っています(ここも2分探索にすれば高速化できる)。また、メモリ利用量を抑えるため、子ノードの配列は正味のサイズだけ確保するようにしています(その分メモリリアロケーションが増えて速度は落ちているはず)。

ちなみに、上記のコードでは、VMの最大メモリ容量が128MBだと、Wikipedia日本語タイトル(127万件)はメモリに載りません(180MB程度必要です。ちなみにlettersをchar[]に、childrenをArrayListではなくNode[]に変えれば載ります)。ですが、まぁ一応機能はするので、次はTrieの特徴であるcommon prefix searchを実装してみます。

Slim3 JSON機能の説明(非公式)

2011-02-02T01:01:00.034+09:00

(2/7更新)
(2/26更新)
(12/22更新 @Jsonはフィールド直接指定になりました)

Slim3 JSON機能のドキュメントを書き始めました。まだ非公式なものですが、ひと通り書き終わったら公式へのマージを提案する予定です。でも、公式は英語なんですよね。どうしたものか。まぁ、いきなり下手な英語で書くより、まずは日本語でちゃんと書いたほうが良いはず。

というわけで、下記ドキュメントの草案です。若干改行が変ですが、evernoteに書きなぐってexportしたものを貼っつけてるためだと思います。これにあとJSON入出力のカスタマイズ方法を書いて一段落とする予定です。(書きました!)

概要

　Slim3のJSON機能は、モデル(@org.slim3.datastore.Modelアノテーションが付加されたクラス)のJSON変換機能を提供します。JSON変換は、org.slim3.datastore.ModelMeta<M>に定義される以下のメソッドを呼び出すことにより行われます。

モデルのJSON文字列への変換:

String modelToJson(Object model);
String modelToJson(Object model, int maxDepth);
String modelsToJson(Object[] models);
String modelsToJson(Object[] models, int maxDepth);

JSON文字列のモデルへの変換:

M jsonToModel(String json);
M jsonToModel(String json, int maxDepth);
M[] jsonToModels(String json);
M[] jsonToModels(String json, int maxDepth);

　例えばTestModelというモデルに対してJSON変換機能を使用するコードは、次のようになります。

TestModel m = new TestModel();
m.setValue(1);
String json = TestModelMeta.get().modelToJson(m);
System.out.println(json); // {"value": 1}
TestModel m2 = TestModelMeta.get().jsonToModel(json);
Assert.assertEquals(m.getValue(), m2.getValue());

JSON変換の制御

　フィールドにJSONアノテーション(@org.slim3.datastore.json.JSON)を指定することで、JSON変換の振る舞いを変更できます。以下にJSONアノテーションで指定できるパラメータを示します。

パラメータ名	型	デフォルト	説明
ignore	boolean	false	このアトリビュートを無視します。JSON出力に含まれず、JSON入力時にも読み込まれません。
ignoreNull	boolean	true	アトリビュートがnullの場合、何も出力しません。falseの場合は、"null"が出力されます。
alias	String	空文字列	アトリビュートのJSON文字列内での名前を指定します。
coder	Class<? extends JsonCoder>	Default.class	JSON入出力を行うJsonCoderのクラスを指定します。ここに独自のクラスを指定することで、JSON入出力のカスタマイズを行うことができます(後述)。

　例えばプロパティを無視したり、エイリアスを設定したりする場合、以下のように記述します。

@Model
class TestModel{
  ...
  @Json(ignore=true)
  private String ignoredValue;
  @Json(alise="foo")
  private String bar;
}

対応する値型

　Slim3のJSON変換機能は、以下の値型に対応します。また、後述するカスタマイズを行えば、これ以外の型に対応したり、入出力方法を変更する事ができます。

Javaクラス	JSON表現	例
java.lang.String, com.google.appengine.api.datastore.Text	文字列。cipher=trueの場合、JSON内では暗号化されます。	"text":"hello"
byte[], com.google.appengine.api.datastore.ShortBlob, com.google.appengine.api.datastore.Blob	バイト列のBase64文字列。	"blob":"mMB4qZAgtBKJq0d1LBGTCA=="
boolean, java.lang.Boolean	ブール値(true or false)。	"value":true
short, java.lang.Short, int, java.lang.Integer, long, java.lang.Long	整数。	"value":100
float, java.lang.Float, double, java.lang.Double	小数。	"value":1.0
java.util.Date	整数(Date.getTime()が返す値)。	"value":10233400
java.lang.Enum	文字列(Enum.name()が返す値)。	"value":"MONDAY"
com.google.appengine.api.users.User	ネストしたJSON文字列(User.getEmail()等の値をJSONエンコード)。	"user":{"authDomain":"authDomain","email":"user@test.com"}
com.google.appengine.api.datastore.Key	文字列(KeyFactory.keyToString(Key)の実行結果)。	"key":"aglzbGltMy1nZW5yCwsSBHRlc3QY6AcM"
com.google.appengine.api.datastore.Category	文字列(Category.getCategory()の値)。	"category":"partOfSpeech"
com.google.appengine.api.datastore.Email	文字列(Email.getEmail()の値)。	"mail":"user@domain.tld"
com.google.appengine.api.datastore.GeoPt	ネストしたJSON文字列(GeoPt.getLatitude()及びGeoPt.getLongitude()の値をJSONエンコード)。	"geopt":{"latitude":10.0,"longitude":10.0}
com.google.appengine.api.datastore.IMHandle	ネストしたJSON文字列(IMHandle.getAddress()及びIMHandle.getProtocol()の値をJSONエンコード)。	"handle":{"address":"handle","protocol":"xmpp"}
com.google.appengine.api.datastore.Link	文字列(Link.getValue()の値)。	"link":"linkValue"
com.google.appengine.api.datastore.PhoneNumber	文字列(PhoneNumber.getNumber()の値)。	"phone":"000-000-000"
com.google.appengine.api.datastore.PostalAddress	文字列(PostalAddress.getAddress()の値)。	"address":"Tokyo, Japan"
com.google.appengine.api.datastore.Rating	整数(Rating.getRating()の値)。	"rating":100
com.google.appengine.api.blobstore.BlobKey	文字列(BlobKey.getKeyString()の値)。	"blobkey":"Q3PqkweYlb4iWpp0BVw"
org.slim3.datastore.ModelRef<M>	文字列(モデルのkeyに対してKeyFactory.keyToString(key)した結果)。	"ref":{"key":"lskfo2ijalefkwejfwlke",value:100}

　また上記サポートする型のコレクションにも対応しています。対応するコレクションクラスはjava.util.List, java.util.Set, java.util.SortedSetで、JSON文字列からモデルを作成する際は、それぞれjava.util.ArrayList、java.util.HashSet、java.util.TreeSetをnewして要素を追加したものがセットされます。

ModelRef<M>の展開

　デフォルトではJSONアノテーションのcoderパラメータにorg.slim3.datastore.json.Defaultが指定されたものとして扱われ、このクラスは、ModelRefを参照先のモデルのキーに変換します。参照先のモデルの内容を展開したい場合、org.slim3.datastore.json.Expandedを指定して下さい。このクラスは、参照先のモデルの内容を展開し、そのモデルがさらにModelRefを持っている場合も展開します。展開のネストの深さは、modelToJsonメソッドやjsonToModelメソッドの、maxDepth引数で制限できます。

　以下にコード例を示します。

@Model
class TestModel{
  ...
  @Json(coder=Expanded.class)
  private ModelRef<TestModel> ref = new ModelRef<TestModel>(TestModel.class);
}
...
TestModel m = new TestModel();
TestModelMeta.get().modelToJson(m, 3);  // 3階層まで展開

JSON入出力のカスタマイズ

　JSONアノテーションのcoderパラメータにJSON入出力を行うクラスを指定することにより、JSON変換の振る舞いを変更することができます。デフォルトではorg.slim3.datastore.json.Defaultが指定されており、slim3が対応するデータ型のJSON入出力が行われます。slim3ではもう一つ、org.slim3.datastore.json.Expandedが用意されていて、これをModelRef<M>型のフィールドに対して使用すると、ModelRef<M>が参照しているオブジェクトも展開します。

　slim3が対応していないデータ型を使う場合や入出力方法を変更したい場合は、org.slim3.datastore.json.Defaultから継承したクラスを作成し、encode/decodeメソッドをオーバーライドして下さい。

　下記にjava.awt.Pointの入出力をサポートするクラスの例を示します。

class CustomCoder extends org.slim3.datastore.json.Default{
  public void encode(JsonWriter writer, Object value){
    if(value instanceof java.awt.Point){
      java.awt.Point pt = (java.awt.Point)value;
      writer.beginObject();
      writer.writeValueProperty("x", pt.x);
      writer.writeValueProperty("y", pt.y);
      writer.endObject();
    } else{
      super.encode(writer, value);
  }
  public <T> T decode(JsonReader reader, T defaultValue, Class<T> clazz){
    if(java.awt.Point.isAssignableFrom(clazz)){
      try{
        int x = Integer.parseInt(reader.readProperty("x");
        int y = Integer.parseInt(reader.readProperty("y");
        return clazz.cast(new Point(x, y));
      } catch(NumberFormatException e){
      }
    }
    return defaultValue;
  }
}

　java.awt.PointクラスのフィールドをJSON入出力の対象にするには、上記のCustomCoderをcoderパラメータに指定します。

import java.awt.Point;

@Model
class TestModel{
  public Key getKey(){
    return key;
  }

  public void setKey(Key key){
    this.key = key;
  }

  public Point getPoint(){
    return point;
  }

  public void setPoint(Point point){
    this.point = point;
  }

  @Attribute(primariKey=true)
  private Key key;

  @Attribute(persistent=false)
  @Json(coder=CustomCoder.class)
  private Point point;

}

　上記のように指定すると、java.awt.Point型のpointフィールドのJSON入出力がおこなえるようになります。

TestModel m = new TestModel();
m.setPoint(new Point(10, 20));
String json = TestModelMeta.get().modelToJson(m); // {"point":{"x":10,"y":20}}
TestModel m2 = TestModelMeta.get().jsonToModel(json);
Assert.assertEquals(m.x, m2.x);
Assert.assertEquals(m.y, m2.y);

AppEngine Java で絵文字入りメールを送信する

2011-01-02T14:45:00.004+09:00

Google AppEngineで絵文字メールを送る方法を紹介します。AppEngineでは送信メールのエンコーディングを指定できない( issueへのリンク)ため、絵文字を送ることはできないと思っていたんですが、 @tmurakamiさんに、送る方法を教えてもらいました。ただし、今のところこの方法で動作確認が出来ているのは、auのW62T, W63H, W64Kのみです。また、AppEngineの振る舞いに依存しているため、今後も動くかどうかの保証はありません。また、メールをWebメール等に転送している場合、Webメール側(au oneとgmailで確認されています)ではメール全体が(絵文字部分だけでなく)正常に表示されないようです(ヘッダにあるエンコーディング情報とメールボディのエンコーディングが違うので無理も無いですが)。

方法は至ってシンプルで、JISエンコード済みのテキストを無理やりStringに入れるというものです。例えばスマイルマーク(ucs: ☺, au: )であれば、auでの文字コードは0x7656なので、以下のようにします。

String text = new String(
   new byte[]{0x1b, '$', 'B', 0x76, 0x56, 0x1b, '(', 'B'}
   , "ISO8859-1");

0x1b, '$', 'B'はJIS漢字を開始するエスケープシーケンス、0x1b, '(', 'B'はアスキー文字を開始するエスケープシーケンスです。こうやって作った文字列を、メールの本文に設定します。

MailService.Message m = new MailService.Message();
 m.setTextBody(text);
 // set sender, recipients and subject
 MailServiceFactory.getMailService().send(m);

ここでは触れませんが、JavaMailApiでは、ByteArrayDataSourceを使うと送れるそうです。

AppEngineはメールを送信する際、含まれているキャラクタを見て、エンコーディングを決定します。日本語が含まれていればISO2022JPを選択しますし、中国語であればBig5、UTF8になる場合もあります。上記のように制御コードが混じっていると、ISO8859-1として、そのまま送信するようです。そして実機ではエンコーディングを無視してISO2022JPとして表示するため、絵文字が表示できる、という仕組みです。ただしこのAppEngineの振る舞いは規定されているものではないので、今後も動き続ける保証はありません。

pos2witではこの方法を使って、絵文字の送信機能を実装しました(今のところauのみ)。ダッシュボードから有効にできるので、au携帯でお使いの方は是非試してみてください。また、今後他社の携帯も調査して、可能であれば対応する予定です。

JSON変換機能、slim3にマージ中

2010-11-20T01:06:00.000+09:00

以前のエントリで書いたslim3モデルのJSON変換機能ですが、slim3のコミッターになってマージ中です！

ロードマップはこんな感じ。

1st step (完了).
・modelToJsonメソッドの追加。基礎的な仕組みの実装。
・short, int, long, float, double及びそれらのラッパークラスのJSON出力実装。
・StringのJSON出力実装(cipher=trueを考慮)。
・ラッパークラスとStringのList, Set, SortedSetのJSON出力実装。

2nd step (完了).
・AppEngine固有の型(Blob, Category, Email, GeoPt, IMHandle, Link,
PhoneNumber, PostalAddress, Rating, ShortBlob, Text, UserのJSON出力実装。
・Date, EnumのJSON出力実装。
・上記の型のList, Set, SortedSetのJSON出力実装。

3rd step以降.
・リファクタリング
・ModelRef対応。
・シリアライズ対応(おそらくシリアライズしてBase64)
・アノテーションによる制御の検討(フィールド名のエイリアスとか、JSON変換時は無視するとか)
・jsonToModelメソッド追加(と上記の型の対応)。

実装の途中経過は、適宜slim3のDiscussion Groupでお知らせしてます。

slim3を改造して、モデルのJSON変換機能を追加する

2010-11-09T23:44:00.002+09:00

Google App Engine for Java用のフレームワークと言えばslim3です。シンプルで非常に使いやすいフレームワークですが、その特徴はアノテーションプロセッサとして実装されている、Metaクラスジェネレータ(slim3-gen)にも当てはまります。拡張性が考慮されていて、簡単に機能を拡張することが出来るようになっていて、実際にアノテーションの情報を元にソースを生成するサンプルも公開されています(リポジトリの、slim3-gen-extention-sample)。

そのサンプルを参考に、slim3-genが生成するメタクラスにjson変換を行うメソッドを追加する拡張、slim3-gen-jsonicを作ってみたので、紹介します。

使い方

slim3-gen-jsonicのバイナリを、ここからダウンロードして下さい(現在最新版はslim3-gen-jsonic-1.0.5.jar)。
次に、jsonicのバイナリをjsonicのサイトからダウンロードして下さい(現在最新版はjsonic-1.2.4.jar)。

slim3と使う場合と同様にプロジェクトを作成、セットアップし(slim3のスタートガイド参照)、jsonicのjarをビルドパスに追加、slim3-genのjar(現在最新はslim3-gen-1.0.5.jar)の代わりにslim3-gen-jsonicのjarを使用すると、モデルごとに生成されるメタクラスに以下のメソッドが追加されます。

public String modelToJson(Object model)
public ModelClass jsonToModel(String json)

ModelClassは、各モデルのクラスに置き換わります。

modelToJsonでモデルをJSON文字列に変換し、jsonToModelでその逆、JSON文字列をモデルに変換します。jsonToModelは、内部でJSONICを使っています。使い方は簡単、Metaクラスからこれらのメソッドを呼び出すだけです。

public void test(){
  TestModelMeta m = TestModelMeta.get();
  TestModel model = new TestModel();
  String json = m.modelToJson(model); // model -> JSON
  TestModel model2 = m.jsonToModel(json); // JSON -> model
}

対応している型

現在、以下の型に対応しています。

String(cipher=trueの場合、JSON出力時に暗号化されます), List<String>, Set<String>, SortedSet<String>
short, Short, List<Short>, Set<Short>, SortedSet<Short>
int, Integer, List<Integer>, Set<Integer>, SortedSet<Integer>
long, Long, List<Long>, Set<Long>, SortedSet<Long>
float, Float, List<Float>, Set<Float>, SortedSet<Float>
double, Double, List<Double>, Set<Double>, SortedSet<Double>

ソースからのビルド

EclipseとGoogle Plugin for Eclipse、Subversionクライアント(Subclipse or subversive)が必要です。

まず、slim3のリポジトリから、slim3とslim3-genをチェックアウトします。

次に、slim3-gen-jsonicのリポジトリから、slim3-gen-jsonic、slim3-gen-jsonic-testをチェックアウトします。

slim3-gen-jsonicに含まれているbuild.xmlを使ってビルドすると、slim3-gen-jsonicプロジェクトのtargetディレクトリに、jarファイルが生成されます(slim3-genの全クラスもこのjarに含まれています)。

slim3-gen-jsonic-testプロジェクトは、slim3プロジェクトを参照し、slim3-gen-jsonicプロジェクトが生成するjarをannotation processorとして参照しるので、このプロジェクト内にモデルクラスを作成すると、JSON変換機能を簡単に試せます。また、メタクラスはsrc_generatedディレクトリ内に生成されるようになっているので、実際にどんなメソッドが生成されているか確認できます。

jsonic単体と比べた利点

今のところ持っている機能だと、文字列の暗号化対応以外、jsonicそのものを使っても同じ効果が得られます。slim3-genに統合する形で機能を追加していく利点としては、

リフレクションを使わないので速い(但しある程度大きなモデルでも、数十ミリ秒の差でしょう)
App Engine固有の型に対応しやすい(固有の型には今後対応していく予定です)

というところが挙げられます。まぁ、あまり大きな利点は無いですし、DatastoreのモデルとJSONとしてクライアントに返すデータのモデルが同じものとも限らない(むしろ別々に設計したほうがよさそう)ですが、Metaを使ってモデルを手軽に変換できるだけでも便利なのではないかと思います。

pos2wit - メールでTwitterを利用できる無料サービス

2010-11-08T23:00:00.008+09:00

趣味でpos2witの開発を始めて、気づけばもう1年が経ちました。当初予定していたよりも多くの機能が実装できて、かなり便利に使えるツールになってきました。このスマートフォン全盛の時代、あえてガラケーのみで勝負する人のためのサービスです :-)

pos2witはメールでTwitterを利用出来るサービスです。特に携帯電話のメール機能に最適化してあり、携帯電話のメール機能を使って、Twitterの機能を一通り使うことが出来ます。写真の添付や他のユーザが投稿した写真のサムネイル取得にも対応しています。

ガラケーしか持っていない人、特にメール無料プランを契約している人に最適です(私もガラケーでメール無料プランです!)。通勤途中や休憩時間の暇つぶしなど、ちょっとした時間に是非ご活用ください!

注意事項: pos2witはGoogle App Engine上で動作しており、Twitterにアクセスします。そのため、App EngineのメンテナンスやTwitterのAPI制限に影響され、機能が正常に使えないことがあります。多くの機能は失敗することは殆どありませんが、検索については、TwitterのAPI制限のため、一定時間使えない状態になっていることがあります。そのため、検索結果の受信には、数分から数時間かかることがあります。

ユーザ登録

ユーザ登録は、PCからの登録(oAuth)と、メール経由の登録(xAuth)の2種類に対応しています。

PCから登録する場合、www.pos2wit.comにある、"Signin with Twitter"と書かれたボタンをクリックしてください。Twitterアカウントへのアクセスを許可する画面が表示されます。"許可する"を選ぶと、ユーザ登録が完了しますので、利用するメールアドレスを登録してください。登録後送られる確認メールに返信すると、メールが登録され、pos2witが利用出来るようになります。

メール経由で登録する場合、1行目にTwitterのIDを、2行目にパスワードを書いたメールを、reg@pos2wit.com に送信してください。ユーザ登録とメール登録が一度に行われ、pos2witが利用出来るようになります。(このとき送られたID, パスワードは、Twitterへのアクセス情報の取得にのみ使われ、取得後破棄されます。pos2wit登録後にパスワードを変更しても、動作に問題はありません。)

※迷惑メールフィルタを利用されている場合、pos2wit.comから送信されるメールを受信できるように設定しておいてください。

投稿機能

内容にTwitterに投稿したいツイートを記入して p@pos2wit.com にメールを送ると、Twitterに書き込むことが出来ます(件名は無視されます)。この際、写真が添付されていると、TwitPicに写真が投稿され、URLがツイートの末尾に付加されます。投稿先の画像サービスは、PCから pos2wit にログインした際に表示される、ダッシュボード画面で変更できます。

また、画像を投稿する際に、回転や反転などのフィルターを適用できます。件名にrlで左回転、rrで右回転を行ないます(このエントリ末尾に詳細)。

タイムライン取得

h@pos2wit.com に空メールを送ると、ホームタイムラインが取得できます。メールの受信可能サイズ制限のため、通常取得できるツイートは10〜20件程度です。sh@pos2wit.com に空メールを送ると、装飾のほとんどない、簡易フォーマットでホームタイムラインが取得できます。この場合、40〜50件程度のツイートが取得できます。

ユーザのタイムラインやステータス、お気に入り、リツイート、返信、ハッシュタグの検索、画像のサムネイル取得、イベント概要(ATND, TweetVite)取得、グルーポン概要取得など、ホームタイムラインの結果には様々な操作を行うためのメールアドレスへのリンクが貼られます。これはツイートの内容を解析することで実現されていて、短縮URLも展開して解析しています。

発表(App Engine Java Night Kansai #3)

先月京都リサーチパークで行われたAJNK3で発表しました! ustと資料はこちらからどうぞ(途中までだけど)

また、AJNK3では、slim3のひがやすをさん、teamsteamのpirosukeさんも発表されています。

各種機能の詳細

画像投稿先として対応しているサービス

twitpic
twitgoo
plixi
yfrog
img.ly
picasa

画像投稿時のフィルタ(件名に記入)

rl - 左回転(90℃)
rr - 右回転(90℃)
rp - 半回転(180℃)
fh - 上下反転
fv - 左右反転
ifh - 自動輝度調整
sNN - 縮小(例: s30 - 30%に縮小)

サムネイル取得に対応しているサービス

twitpic
twitgoo
plixi
yfrog
flickr
brizzly
owly
携帯百景
mobypic

Twitter4J 2.1.2を改造してGoogle AppEngineからTwitPicにOAuthEchoで画像を投稿する。

2010-07-08T23:58:00.009+09:00

Twitter4J2.1.2では(執筆時はまだ開発中)、画像の投稿機能が提供されます。現在実装されているのは、YFrogへの投稿機能(OAuthEcho, Basic認証)とTwitPicへの投稿機能(Basic認証のみ)です。
pos2witではTwitPicへのOAuthEchoによる投稿を行いたかったので、できるように改造してみました。

まず、Twitter4Jのサイトから、バージョン2.1.2をダウンロードして展開して下さい。この中に含まれる、twitter-core内のソースを改造しますので、このソースが改造できる環境を整えて下さい(僕はEclipse上にプロジェクトを作成し、ソースをコピーしました。)。環境を整えてコンパイルすると、twitter4j.internal.logging内のいくつかのソースでコンパイルエラーが起こります。参照しているクラスがないためで、ここは何も考えずにCommonsLogging, Log4J, SLF4J関連のソースを削除します(それぞれLoggerとLoggerFactoryがあるのでそれらを削除)。

次にgithubのtwitter4j.utilから、ImageUpload.javaをダウンロードし、twitter4j.util内にコピーします。このファイル内で、画像投稿機能が実装されています。
コピーするとコンパイルエラーが出るので、まずはこれを潰します。

twitter4j.http.OAuthAuthorizationに、次のメソッドを追加します(これはgit内のソースには実装されています)。


    public List<HttpParameter> generateOAuthSignatureHttpParams (String method, String url) {
        long timestamp = System.currentTimeMillis() / 1000;
        long nonce = timestamp + RAND.nextInt();
        
        List<HttpParameter> oauthHeaderParams = new ArrayList<HttpParameter>(5);
        oauthHeaderParams.add(new HttpParameter("oauth_consumer_key", consumerKey));
        oauthHeaderParams.add(OAUTH_SIGNATURE_METHOD);
        oauthHeaderParams.add(new HttpParameter("oauth_timestamp", timestamp));
        oauthHeaderParams.add(new HttpParameter("oauth_nonce", nonce));
        oauthHeaderParams.add(new HttpParameter("oauth_version", "1.0"));
        if (null != oauthToken) {
            oauthHeaderParams.add(new HttpParameter("oauth_token", oauthToken.getToken()));
        }
        
        List<HttpParameter> signatureBaseParams = new ArrayList<HttpParameter> (oauthHeaderParams.size());
        signatureBaseParams.addAll(oauthHeaderParams);
        parseGetParameters (url, signatureBaseParams);
        
        StringBuffer base = new StringBuffer (method).append("&")
                .append(encode(constructRequestURL(url))).append("&");
        base.append(encode (normalizeRequestParameters(signatureBaseParams)));

        String oauthBaseString = base.toString();
        String signature = generateSignature (oauthBaseString, oauthToken);

        oauthHeaderParams.add (new HttpParameter("oauth_signature", signature));
        
        return oauthHeaderParams;
    }

次に、ImageUpload.java内にTwitPic用のOAuth Echo対応ImageUploadを実装します。
同ファイル内に、下記のソースをコピーします。下記ソースは、同ファイル内のYFrogOAuthUploaderをコピーしてTwitPic用に修正したものです。


// import部分
import java.io.InputStream;
import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;
import twitter4j.conf.Configuration;
import twitter4j.conf.ConfigurationContext;
import twitter4j.internal.org.json.JSONException;
import twitter4j.internal.org.json.JSONObject;

// TwitPicOAuthUploader
    public static class TwitPicOAuthUploader extends ImageUpload {
     private String apiKey;
        private OAuthAuthorization auth;

        // uses the secure upload URL, not the one specified in the YFrog FAQ
        private static final String TWITPIC_UPLOAD_URL = "http://api.twitpic.com/2/upload.json";
        private static final String TWITTER_VERIFY_CREDENTIALS = "https://api.twitter.com/1/account/verify_credentials.json";

        public TwitPicOAuthUploader(String apiKey, OAuthAuthorization auth) {
            this.apiKey = apiKey;
            this.auth = auth;
        }

        public String upload(File image) throws TwitterException{
         throw new UnsupportedOperationException();  // AppEngineではFileInputStreamが使えない。
        }

        public String upload(String message, String fileName, InputStream fileBody) throws TwitterException {
            // step 1 - generate verification URL
//            String signedVerifyCredentialsURL = generateSignedVerifyCredentialsURL();

            // step 2 - generate HTTP parameters
            HttpParameter[] params = {
                    new HttpParameter("key", apiKey)
                 , new HttpParameter("message", message, true)
                    , new HttpParameter("media", fileName, fileBody)
                    };

            // step 3 - upload the file
            Configuration config = ConfigurationContext.getInstance();
            config.getRequestHeaders().put("X-Auth-Service-Provider", TWITTER_VERIFY_CREDENTIALS);
            StringBuilder b = new StringBuilder();
            b.append("OAuth realm=\"http://api.twitter.com/\"");
            for(HttpParameter p : auth.generateOAuthSignatureHttpParams("GET", TWITTER_VERIFY_CREDENTIALS)){
             if(p.getName().equals("oauth_signature")){
                    try {
                        b.append(", ").append(p.getName()).append("=\"").append(
                                URLEncoder.encode(p.getValue(), "ISO8859_1")
                                ).append("\"");
                    } catch (UnsupportedEncodingException e) {
                        throw new TwitterException(e);
                    }
             } else{
                    b.append(", ").append(p.getName()).append("=\"").append(p.getValue()).append("\"");
                }
            }
            config.getRequestHeaders().put("X-Verify-Credentials-Authorization", b.toString());
            System.out.println("X-Auth-Service-Provider: " + TWITTER_VERIFY_CREDENTIALS);
            System.out.println("X-Verify-Credentials-Authorization: " + b.toString());
            HttpClientWrapper client = new HttpClientWrapper(config);
            HttpResponse httpResponse = client.post(TWITPIC_UPLOAD_URL, params);

            // step 4 - check the response
            int statusCode = httpResponse.getStatusCode();
            if (statusCode != 200) {
                throw new TwitterException("Twitpic image upload returned invalid status code", httpResponse);
            }

            try{
             String response = httpResponse.asString();
             return new JSONObject(response).getString("url");
            } catch(JSONException e){
                throw new TwitterException("Unknown Twitpic response", httpResponse);
            }
        }
    }

上記のソースをペーストすると、twitter4j.internal.http.HttpParameterに必要なメソッドが無いためにコンパイルエラーが発生します。下記のフィールド及びメソッドを、HttpParameterクラスに追加して下さい。


    // フィールドを追加
    private boolean noUrlEncode = false;
    private InputStream fileBody = null;
    ...

    // コンストラクタを追加
    public HttpParameter(String name, String value, boolean noUrlEncode) {
        this.name = name;
        this.value = value;
        this.noUrlEncode = noUrlEncode;
    }

    public HttpParameter(String name, String fileName, InputStream fileBody) {
        this.name = name;
        this.file = new File(fileName);
        this.fileBody = fileBody;
    }
    ...

    // メソッドを追加
    public boolean isUrlEncodeUnnecessary(){
     return this.urlEncodeUnnecessary;
    }

    public boolean hasFileBody(){
     return null != fileBody;
    }

    public InputStream getFileBody(){
     return fileBody;
    }

これでコンパイルエラー自体は消えますが、追加されたパラメータに対応してリクエスト作成機能を修正する必要があります。リクエスト作成機能はtwitter4j.internal.http.HttpClientImpl.java内にあるので、下記のように改造します(赤字が改造部分)。

                                // 241行目あたり
                                if(param.isFile()){
                                    write(out, boundary + "\r\n");
                                    write(out, "Content-Disposition: form-data; name=\"" + param.getName() + "\"; filename=\"" + param.getFile().getName() + "\"\r\n");
                                    write(out, "Content-Type: " + param.getContentType() + "\r\n\r\n");
                                    BufferedInputStream in = new BufferedInputStream(
                                      param.hasFileBody() ? param.getFileBody() : new FileInputStream(param.getFile())
                                      );
                                    int buff = 0;
                                    ...

                                // 258行目あたり
                                    logger.debug(param.getValue());
                                    if(param.isUrlEncodeUnnecessary()){
                                     out.write(param.getValue().getBytes("UTF-8"));
                                    } else{
                                     out.write(encode(param.getValue()).getBytes("UTF-8"));
                                    }
                                    write(out, "\r\n");
                                    ...

この修正が必要なのは、

オリジナルのコードではFileInputStreamを使っているが、これはAppEngineでは使えない。
オリジナルのコードでは常にパラメータをURLEncodeしているが、メッセージをURLEncodeするとTwitPicで復元されない(URLEncodeされた状態で記録される)

という問題に対処するためです。

これでTwitPicに画像を投稿できるようになります。サンプルコードはこんな感じ。投稿にはTwitPicのAPIKEYが必要なので、ここからアプリケーションを登録し、APIKEYを入手して下さい。

 public void test() throws Exception{
  String apiKey = TwitPicのAPI KEY;
  Twitter t = new TwitterFactory().getOAuthAuthorizedInstance(new AccessToken(
    Twitterユーザのaccess_token
    , Twitterユーザのaccess_token_secret
    ));
  OAuthAuthorization auth = (OAuthAuthorization)t.getAuthorization();
  String message = "投稿するメッセージ。";
  String url = new ImageUpload.TwitpicOAuthUploader(apiKey, auth).upload(
    message, "duke.jpg", getClass().getResourceAsStream("duke-on-gae.jpg")
    );
  // twitterには、別途投稿する必要がある(uploadでは写真がTwitPicに投稿されるのみ)。
  t.updateStatus(message + " " + url);
 }

だいぶ汚い改造になってしまいましたが、とりあえず投稿することはできるようになりました。もう少し整理して、Twitter4Jにうまく取り込んでもらえるよう働きかける予定です。

AJDT2.1.0 Released

2010-07-08T23:16:00.001+09:00

AJDT2.1.0がリリースされました。リリースノートに書かれている変更点をざくっと紹介します。主にITD(Inter Type Definition)関連の機能が強化されました。

ITD-Aware Search
アスペクトによる定義の追加を考慮したJava Searchが正しく行われるようになりました(例: ITD定義、String Person.getName()に対して参照の検索を行うと、ITDされたメソッドを使用しているコードがヒットする)。

ITD rename refactoring
名前変更のリファクタリング機能がITDに対応しました。アスペクトのITDでの名称変更(例: String Person.getName()をString Person.getFirstName()に)を行うと、影響を受ける定義(例: Personの派生クラスでのgetNameメソッド(オーバーライド))も名称変更されます。

ITD-aware renaming of getters and setters
フィールドの名称変更を行う際に、ITDによって実装されていたそのフィールドのgetter及びsetterの名称変更も行えるようになりました。nameをfirstNameに変更した場合に、ITDで実装されたgetNameがgetFirstNameに、setNameがsetFirstNameに変更されませす。(但し、Personの派生クラスでgetNameをオーバーライドしていた場合、そのメソッドは変更されません(あくまでgetter/setterのみ)。個人的にはこれも変更されて欲しいところ。常に@Override付けといた方が良さそうですね。)

Pull-out refactoring
フィールドやメソッドを、ITDとして特定のアスペクトに移動するリファクタリング。パッケージエクスプローラでフィールドやメソッドを選んで右クリック -> Refactory -> Pull Out ITD... と選択すると、既存のアスペクトに切り出せます。

Aspect-aware type renaming
クラス名の変更を行う際に、それを参照しているアスペクト内での定義(ITD)も適切に変更されるようになりました。

@Test and Intertype declarations
ITDによって@Testが付加されたメソッドを追加した場合、そのクラスをテストすると、@Testが付加されたメソッドもテストの対象になります。

AspectJ-aware PDE Build (Helios only)
AspectJをPDEに統合したビルドが提供されるようになったそうです。AspectJに依存したプラグインを作る際に、Javaプラグインと同じウィザード等を使えるようになりました。詳しくはこちら。

Modernize the build server
ビルドサーバーをモダンなものに変えたそうです。詳しくはこちら。

AspectJ 1.6.9
最新のAspectJ 1.6.9がバンドルされています。readmeはこちら。

Bug Fixes
その他、いくつかのバグが修正されています。

最初ITDがサポートされるようになった頃は、IDE上はコンパイルエラーになっていましたが、バージョンを重ねるにつれて洗練され、遂にリファクタリングまで正常に動くようになりました。今回の機能強化で、ITDされたメソッド・フィールドも元からクラスに定義されていたものとほぼ同じように扱われるようになり、心おきなく使えるようになったのではないでしょうか。

wicketのoauth認証サンプルをappengineに載せる

2010-06-19T02:00:00.023+09:00

6/20追記 index.htmlの削除と、エラー処理の修正。

矢野勉さんの記事、Wicketで始めるオブジェクト指向ウェブ開発の第9回　WicketによるOAuth認証を、Google App Engineに載せてみました。appengine上のURLはこちら。

ソースコードの修正は、appengineに載せるための修正と、Twitter4Jの最新版を使うための修正です。

1. ソースコードの入手

第9回のソースコードをダウンロードし、解凍する。

2. AppEngineプロジェクトの作成

Eclipseで新しいAppEngineプロジェクトを作成。プラグインの入手方法やプロジェクトの作成方法はこちら(山下さんの記事)。作成する際に下記の設定を行う。

プロジェクト名はwicket-sample-oauth
パッケージは"jp"
User Google Web Toolkitはオフ

作成後、下記のファイルを削除。(6/20 追記)

war/index.html

3. ライブラリの入手

下記のライブラリをダウンロードし、war/WEB-INF/lib内に必要なjarを置いて、ビルドパスに追加。

Apache Wicket
・wicket-1.4.9.jar
SLF4J
・slf4j-api-1.6.0.jar
・slf4j-jdk14-1.6.0.jar(又はお好みでLog4J用やcommons-logging用を)
Twitter4J
・twitter4j-core-2.1.2.jar

4. ソースコード上書き

解答したソースを、下記のように上書き。

src/main/javaをプロジェクトのsrcに。
src/webapp/WEB-INF/web.xmlをプロジェクトのwar/WEB-INFに。

5. ソースコード修正

上書きしたソースの、下記の部分を修正(赤が変更点)。

jp.gihyo.wicket.TwitterClientを削除。このクラスは、当時のTwitter4Jがシリアライズに対応していないために用意されたクラス。最新版ではシリアライズに対応しているため、不要です。

jp.gihyo.wicket.AppSession#login

下記は、Twitter4Jの最新版を使うための修正です。

    public boolean login(String pin, Response response) {
        try {
            if(requestToken == null) {
                throw new IllegalStateException("requestToken is missing.");
            }

            Twitter client = new TwitterFactory().getInstance();
            client.setOAuthConsumer(consumerKey, consumerSecret);
            
            AccessToken accessToken = client.getOAuthAccessToken(requestToken, pin);
            client = new TwitterFactory().getOAuthAuthorizedInstance(
              consumerKey, consumerSecret, accessToken);
            this.twitterSession = client;
            dirty();
            return true;
        } catch(TwitterException ex) {
            LOGGER.error("Can not setup OAuth Access Token to Twitter object.", ex);
            return false;
        }
    }

jp.gihyo.wicket.AppSession#getTwitterSession

下記は、Twitter4Jの最新版を使うための修正です。

    public Twitter getTwitterSession(Request request) {
        if(request == null) throw new IllegalArgumentException("'request' is missing");

        //既にTwitterオブジェクトを作成済みなら，認証の必要はない。
        if(twitterSession != null) return twitterSession;

        //AccessTokenをDBなどに永続化している場合は，ここで永続化したAccessTokenを使って
        //Twitterオブジェクトを再作成して返却すればよい。
        //このサンプルではAccessTokenを永続化していないので，すぐにOAuth認証に入る。

        //OAuth認証開始。RequestTokenの取得を試みる。
        Twitter client = new TwitterFactory().getInstance();
        client.setOAuthConsumer(consumerKey, consumerSecret);
        ...

jp.gihyo.wicket.WicketApplication

以下のメソッドを追加。Wicketアプリケーションをappengineに載せるための設定です。何故これが必要かはここに解説があります。
```
 @Override
 protected ISessionStore newSessionStore() {
  return new HttpSessionStore(this);
 }

 @Override
 public String getConfigurationType() {
     return Application.DEPLOYMENT;
 }
```

jp.gihyo.wicket.AppSession#getTwittersession(6/20 追記)

以下の修正を行う。Twitter呼出時の例外を修正。Twitterがエラーを返した場合の処理を改善します。


    public Twitter getTwitterSession(Request request) throws TwitterException{
        if(request == null) throw new IllegalArgumentException("'request' is missing");

        //既にTwitterオブジェクトを作成済みなら，認証の必要はない。
        if(twitterSession != null) return twitterSession;

        ...

        RequestToken token = null;
        try {
            token = client.getOAuthRequestToken(RequestUtils.toAbsolutePath("login"));
        } catch(TwitterException ex) {
            throw ex;
        }
        ...

6. Twitterにアプリケーションを登録

アプリページへ行き、アプリケーションを登録する。
登録方法は、第9回　WicketによるOAuth認証の記事内にあります。

登録後、consumer-keyとconsumer-secretをweb.xml内に設定。

7. セッションを有効にする

war/WEB-INF/appengine-web.xml内に、次の1行を追加する。


 <sessions-enabled>true</sessions-enabled>

以上の設定・変更を行った上で配備すると、appengineでサンプルが動作するようになります。
動作例はこちら

AppEngineでメール送受信とか

2009-11-27T21:46:00.006+09:00

メール受信に関しては、http://d.hatena.ne.jp/hidemon/20091015/1255557396やhttp://d.hatena.ne.jp/nowokay/20091024が参考になります。

送信に関してはhttp://codezine.jp/article/detail/3917に載っているコードがシンプルです。
送信時の注意点は、アプリケーションの開発者のアカウントか、アプリケーションにログイン注のGoogleアカウントしか送信者になれないこと。自分のアカウントを使いたくない場合は、別途Googleアカウントを取得し、それを開発者に加えます(http://code.google.com/intl/ja/appengine/docs/java/mail/overview.htmlここのメールメッセージの節参照)。

pos2witでは、実際に別のGoogleアカウントを取得して、それをアプリケーションの開発者に加え、送信者として設定してます。加えて、そのアカウントに返信されたメールをpos2witで処理するために、フィルタを設定してpos2witの指定アドレスに転送してます。折角メール受信機能があるんだから、APPID.appspotmail.com上のアドレスも送信者として指定できればいいのに。(6/20 追記: 数ヶ月前から、APPID.appspotmail.com上のアドレスも指定できることが確認できてます。英語のドキュメントにもそれが可能であることが触れられています。但し日本語のドキュメントにはまだその記述はありません。)

NavigationToolbarのカスタマイズ

2009-11-23T01:29:00.003+09:00

コーディングでスタイルを変える方法もあるけど、htmlが用意されているコンポーネントの場合は、それを上書きしてしまうことでもカスタマイズできる(但し動的な部分には向かない)。
以下はAjaxFllbackDefaultDataTableのナビゲータである、AjaxNavigationToolbarの例。　

(AjaxNavigationToolbar.html)

<wicket:panel>
 <tr class="navigation">
  <td wicket:id="span">
   <div style="float: right;" class="navigatorLabel"><span wicket:id="navigatorLabel">[navigator-label]</span></div>
   <div style="text-align: center;" class="navigator"><span wicket:id="navigator">[navigator]</span></div>
  </td>
 </tr>
</wicket:panel>

赤字の部分を書き換えて、本来ラベル(全何件のうち何件目から何件目かを表示)が左でナビゲータ(< < 1 2 3てやつ)が右なのを、それぞれ右、中央に変えてる。
このファイルをプロジェクトのsrc/org/apache/wicket/extensions/ajax/markup/html/repeater/data/table に置いておけば、本来のファイルより優先して読み込まれる。

Wicketのカスタマイズは、コードで、propertyファイルで(これには国際化も絡む)、html置き換え、と複数の方法があってもの凄く柔軟。反面どれでやればいいのかわかりにくいこともありそうだけど。

AjaxFallbackDefaultDataTableのカラム幅指定(2)

2009-11-22T00:23:00.004+09:00

やっぱり簡単な方法があった。

public Page(){
 List<IColumn<Score>> columns = new ArrayList<IColumn<Score>>();
 columns.add(new PropertyColumn<Score>(new Model<String>("打順"), "order"){
  public String getCssClass() {
   return "orderClass";
  }
 });
 add(new AjaxFallbackDefaultDataTable<Score>(
  "scores", columns
  , new ScoreDataProvider(), 10
  ));

こんな感じで、カラムのgetCssClassをオーバーライドして適当な値を返せばthタグのclassとして出力されるので、スタイルシートで


 th.orderClass{ width: 20%}

ってやっとけば幅を指定できる。前回のコードからわかるように、Columnは実際にはthやtdの下に位置するんだけど、getCssClassが返す結果はthやtdに反映される。
前回のと同じ結果ではないけど、はるかにシンプルにできるので、わざわざ前回のコンポーネント階層を辿るより全然良い。

AjaxFallbackDefaultDataTableのカラム幅指定

2009-11-15T00:26:00.002+09:00

AjaxFallbackDefaultDataTableが作ってくれるテーブルの、各カラムのサイズを指定したくていろいろ調べてみたけど、なかなか良い方法が見つからなかった。一応実現できたけど、むちゃくちゃ強引な気がする。


public Page(){
 DataTable table = new AjaxFallbackDefaultDataTable( ... );

 MarkupContainer headers = (MarkupContainer)get(table, "topToolbars/2/toolbar/headers");
 if(headers != null){
  get(headers, "1/header").add(new AttributeAppender("width", new Model("20%"), ""));
  get(headers, "2/header").add(new AttributeAppender("width", new Model("20%"), ""));
  get(headers, "3/header").add(new AttributeAppender("width", new Model("60%"), ""));
 }
}

private static Component get(MarkupContainer root, String path){
 String[] paths = path.split("\\/");
 MarkupContainer current = root;
 for(String p : paths){
  Component c = current.get(p);
  if(c == null) return null;
  if(!(c instanceof MarkupContainer)) return null;
  current = (MarkupContainer)c;
 }
 return current;
}

こんなんでいいのかね。

Wicket勉強中(DropDownChoice)

2009-11-04T10:43:00.005+09:00

Apache Wicketを再勉強中。DropDownChoiceを使う最もシンプルなコードを作ってみた。


public class Sample extends WebPage{
 public Sample() {
  Form form = new Form("form");
  form.add(new DropDownChoice("result"
   , new PropertyModel(this, "resultChoiceSelection")
   , Arrays.asList("エラー", "安打", "二塁打", "三塁打", "ホームラン")
   ));
  form.add(new Button("submit"));
  add(form);
 }
 private String resultChoiceSelection;
}

PropertyModelの行削ったり、変わりにListModelだったりすると、submit時に例外が起こる。これってバグと言っていいと思うけどなぁ。

AJDTやAspectJをベースにしたツールの開発

2008-12-17T22:22:00.000+09:00

Developer's guide to building tools on top of AJDT and AspectJ
AJDTやAspectJをベースにしたツールの開発ガイド。

EclipseプラグインからAJDTを利用する方法や、AspectJのパーザ(.ajファイルパーザ)を利用する方法が解説されてる。

Java6 on MacOS X では Eclipse は動作しない

2008-12-17T22:13:00.000+09:00

どうせならEclipseもJava6上で動かしてやろうと、Info.plistを編集してJava6を指定し、起動するとエラーが出た。

調べてみると、MacのJava6自体は64bitで実装されているが、SWTが32bitにしか対応していないためらしい。

https://bugs.eclipse.org/bugs/show_bug.cgi?id=239301によると、現在SWTをCarbonからCocoaに移植してる(CocoaSWT)最中で、それが終わってから、Eclipse3.5くらいで64bit対応できるといいなぁって程度らしい。

ちなみにCocoaSWTの移植が終わるのはSWT3.5のM6、March 13, 2009。
64bit版はいつになることやら。