天使やカイザーと呼ばれて

package-info.javaをコンパイルするために

Javaにおいて、パッケージにいくつかのアノテーションを指定することができます。これをするために、パッケージ定義のみを持つpackage-info.javaファイルを作成する必要があります。例えば、以下のような感じです。

/**
 * This package includes ... classes.
 * @author Yoichiro Tanaka
 */
package jp.eisbahn.foo.bar;

このpackage-info.javaファイルは、コンパイルすることができます。しかし、上記のケースでは、このファイルは不幸にもコンパイルされないでしょう。その理由は、それが実行時に必要とはjavacコマンドが判断しないからです。それ故に、もしpackage-info.classファイルが欲しい場合は、RUNTIME値を持つ何らかのアノテーションを配置する必要があります。

/**
 * This package includes ... classes.
 * @author Yoichiro Tanaka
 */
@RuntimeAnnotation
package jp.eisbahn.foo.bar;

import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Retention;

@Retention(RetentionPolicy.RUNTIME)
@interface RuntimeAnnotation {}

同じファイルの中で、RetentionPolicyクラスのRUNTIME属性を持つアノテーションを定義できます。そのアノテーションをパッケージに追加することで、そのパッケージは実行時に必要とされることになります。その結果として、そのファイルはjavacコマンドによってコンパイルされるでしょう。

Posted:: 01.07.2010
Category:: Java

基本的に、もしアップデートサイトにPluginやFeatureのJarファイルを配置したい場合、Eclipseアップデートサイトにて定義されたルールに従う必要があります。そのルールとは、site.xmlファイルを作成し、PluginのJarファイルを「plugins」という名前のサブディレクトリに置き、そしてFeatureのJarファイルを「features」という名前のサブディレクトリに置くことです。ユーザがこのアップデートサイトにアクセスしてプラグインをインストールする際に、EclipseはこのルールによってこれらのJarファイルを見つけることができます。

しかし、もしアップデートサイトを作りたいとき、何らかの理由でこれらのサブディレクトリを作れないかもしれません。そのとき、あなたは自由にこれらのファイルを配置したいと考えるでしょう。

このケースの場合、site.xmlファイル内で<archive>タグを使用することができます。このタグの指定により、PluginのJarファイルを任意の場所に配置することができるようになります。もちろん、FeatureのJarファイルは、URLを記述することによって場所を指定できるので、任意の場所に配置することが可能です。

...

Featureが「jp.eisbahn.foo」という名前のPluginを持っているとき、Eclipseは「plugins」という名前のサブディレクトリからそのPluginを探そうとするでしょう。そのとき、PluginのJarファイルのパスは、「plugins/jp.eisbahn.foo_1.0.0.jar」となります（バージョン番号が1.0.0の例）。そして、<archive>タグを使うことで、そのパスを任意のURLに置き換えることができます。上記の例では、そのパスは「http://www.eisbahn.jp/any/foo-plugin.jar」に置き換えられています。

このテクニックは、OSDEのアップデートサイトで使用されました。そのsite.xmlファイルは以下となります。

http://opensocial-development-environment.googlecode.com/svn/update-site-candidate/site.xml

Posted:: 01.04.2010
Category:: Eclipse

Eclipseプラグイン勉強会に参加してきました

昨日の15日に、Eclipseプラグイン開発のための勉強会「EclipSKY」に参加してきました。
竹添さん著のEclipseプラグイン開発本である「Eclipse 3.4 プラグイン開発徹底攻略(青本) 」を持参することが参加の条件でした（半分ホント）。もちろん全員持参してきました。

テーマとして、OpenSocialアプリケーションの開発環境であるOpenSocial Development Environment(OSDE)の紹介と、OSDEの中で「ここは便利」「ここはイケてない」という箇所を、ソースコードを実際に見ながら議論しました。
[イケてる箇所]
・MasterDetailsBlockの利用
[イケてない箇所]
・例外発生を防ぐための、時間差ILaunch実行（timerExec()で3秒待つ、とか）。
・MultiPageEditorでのページ間の編集内容の同期方法（EditorInputの実装をサボった結果、dirtyフラグ見て自前で同期、とか）

残りのテーマは、ここで紹介されていますので、そちらをどうぞ。
最後に話していたこととして、Eclipseプラグイン開発はやっぱり難しいよね、Ajaxアプリの方がリッチに作れちゃうよね、とか、Eclipseで作ることの意義をどう探していくかが課題なのかなぁ、と。開発環境以外で、結局Eclipseベースでアプリケーションを作る利点って何なんだろう、と考えさせられます。特にユーザエクスペリエンスがいいわけでもないし。。。
次回は「プラグイン開発で困ったことを付箋で貼っていって、みんなで解決！」「AIR開発環境の紹介」がテーマとなりそうです。いつ開催されるかわかりませんが、もしEclipseプラグイン開発に興味があれば、ぜひ次回参加してみてください。

Posted:: 02.16.2009
Category:: Eclipse

Eclipse Plug-in勉強会が明日開催されます

Eclipse Plug-in開発に関する勉強会「EclipSKY」が、明日開催されます。
EclipSKY200902 〜OSDEとかのソースコードからプラグインのコードのおいかけ方を学ぼう
http://atnd.org/events/351
テーマとして、OpenSocialアプリケーションの開発環境である「OpenSocial Development Environment」のコードを見て頂きながら、Eclipse Plug-inの開発に関する知見を参加者の間で共有したいと思っています。
http://www.eisbahn.jp/trac/osde
もしEclipse Plug-in開発に興味がある方は、ぜひご参加ください。

Posted:: 02.14.2009
Category:: Eclipse

WEB+DB PRESS Vol.48が発売されています

WEB+DB PRESSにて連載させていただいている「Java Traveler」、今回で早5回目です。「クラウドコンピューティングプラットフォーム」というキーワードで書かせて頂きました。

WEB+DB PRESS Vol.48

作者: WEB+DB PRESS編集部編
出版社/メーカー: 技術評論社
発売日: 2008/12/23
メディア: 大型本

本当はAmazon Cloud ToolsというJavaEEアプリのデプロイなどをやってくれるツールを取り上げようと考えたのですが、残念ながらうまく動作せず、EC2の課金だけ持って行かれた結果となってしまいました。で、ちょっと方向転換して、Morph AppSpaceとApache Hadoopを取り上げてみました。
他にも興味深い内容でいっぱいです。ぜひ手にしてみてください。

Posted:: 12.22.2008
Category:: Java

HibernateでMapなプロパティを扱う方法

Hibernateを使っていて、ふと困った状況に遭遇。

@Entity @Table(name=”…”) public class Hoge { ・・・ protected Map<String, String> desc; ・・・ }

Hogeエンティティクラスのdescプロパティを永続化させるにはどうしたらいいのだろう？もし、descプロパティが、

protected Map<String, FooBar> desc;

というように、Mapの値が別のエンティティだった場合は、特に問題はない。しかし上記の場合はMapの値がString。これは困った。

Interceptorを自分で作って、onSave()やonFlushDirty()などを実装してstateを入れ替えてみたりして試行錯誤を繰り返すも、残念ながらうまくいかない。そこで、HibernateのForumをいろいろと検索していく中で、同じ話題を発見できた。

[Topic: Map of primitives using CollectionOfElements]
http://forum.hibernate.org/viewtopic.php?t=953403

このトピックの最後に掲載されている投稿に正解が書いてあった。具体的には、

@CollectionOfElements @JoinTable(name=”hoge_desc”, joinColumns=@JoinColumn(name=”hoge_id”) @MapKey(columns=@Column(name=”desc_key”)) @Column(name=”desc_value”, nullable=false) protected Map<String, String> desc;

としてあげることで、descプロパティのためにhoge_desc表が生成され、hogeエンティティとの関連にhoge_id列が、descプロパティのMapのkey値がdesc_key列に、value値がdesc_value値に、それぞれマッピングされて永続化されることになる。

HibernateのReferenceやJavadocには残念ながらズバリの解答は載ってなかったため、半ば諦めかけていた。Hibernate Forum++。

Posted:: 12.11.2008
Category:: Java

遂にJDeveloper 11g登場か！？

と一瞬思ったけど、10gシリーズのマイナーバージョンアップだった。 orz
「The New JDeveloper is Here」 – Shay Shmeltzer’s Weblog
もっと広く使われてもいいと思うんだけどなぁ。僕が知らないだけで、実はあちこちのSIerでめちゃくちゃ利用されてたりするのだろうか。
・ NetBeans – どうしてもAnt or Mavenランチャーにしか見えない。
・ Eclipse – いいんだけど、プラグインの出来がどれも日曜大工程度。
・ IntelliJ – いいんだけど、有償。
というわけで、どの機能をとっても全体的にレベルが高く、そしてフリーなJDeveloperに軍配が上がる（オレオレ判断）。macサポートもいい感じだし、そもそもみんなOracle Database使ってるんだろうし。
やっぱり、ADFとか、Oracle提供の環境に嫌悪感を持ってたりするんだろうか？

Posted:: 07.30.2008
Category:: Java

ドキュメントとして何を書くか？

僕の考えは、以下のような感じ。
(1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。
(2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。
(3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、記述される内容のレベルや粒度などは、各作業者のロールをちゃんと定義してあげれば、おのずと決まってくる。
(4) 完全な自動テストソリューションは、まだ世の中に登場していない、という認識を現在は持つべき。なので、「システムがどう挙動すれば正しいのか」という話は、JUnitやSeleniumなどのコードを書いたからといって「満たした」などと考えてはいけない。「こう操作したらこうなる」というドキュメントを作っておくべきで、それを最終的に「正しい仕様書」に育てることが最優先事項。
特に(3)と(4)の認識の甘いアーキテクトが多すぎる。「自称アーキテクト」という人間であればあるほど、その認識の甘さは宇宙レベル。
プロトタイピングとか、プログラミングファーストとか、近年ではプログラムの動作をまず確認してもらって、妥当であればそれで良し、的な風潮が見え隠れするけど、プロジェクトが完了して成果物が顧客に渡る際には、
・ ○○という人々に□□という目的で△△というドキュメントを書きました。
・このシステムは○○という操作をすると△△という動きをすることを良しとしました。
という2点が揃っていることが、開発側の最低限の責務だと思う。
（注）上記は「釣り」ではなく、大真面目に書きました。

Posted:: 07.22.2008
Category:: Java

WEB+DB PRESS誌にて連載を始めました

先日発売された「WEB+DB PRESS Vol.44」から、「Java Traveler」というテーマで連載を担当させていただくことになった。
第１回目の今回は、「Facebook vs. OpenSocial 次世代インターネット形態の仁義なき戦い」ということで、SNSアプリケーションプラットフォームを紹介してみた。
Facebookは、MySpaceに次ぐアメリカで大ブレイク中のSNS。Facebook Platform上でユーザ自らアプリケーションを開発し、多くの会員に使ってもらうことができる。さらに広告がそれに連動するため、新たなビジネスがそこで生み出されるという効果もあり、非常に注目されている。Googleはそれに対抗してOpenSocialを打ち出し、多くのSNSで共通なAPIを実装してもらうことで、より大きなSNSプラットフォーム戦略による成功を得ようとしている。
どちらも既にアプリケーションを開発し利用してもらう環境が整ってきているため、記事の中で実際のサンプルプログラムを通じて、SNSアプリケーションとはどういう特徴があり、そしてどのように開発していき、どう利用されるのか、そして今後どういう展開を見せるのか、という点についてそれぞれ僕なりの解説をしてみた。同じSNSアプリケーションプラットフォームであるが、アーキテクチャは異なる形態となっているため、その辺の差も取り上げてみた。
ぜひ実際に手に取って、最初の停車駅「SNSアプリケーションプラットフォーム」を体験してみて欲しい。