Java

わんくま同盟富山勉強会レポート

凪瀬 — Wed, 12 Nov 2008 01:10:00 GMT

11/8(土)にわんくま同盟富山勉強会が開催されました。

参加いただいた皆様、スピーカーを引き受けてくださった皆様、ネットから視聴していただいた皆様、どうもありがとうございました。

Wicketで変わるウェブ・アプリケーション開発

矢野勉氏のWicketのセッション。私が忘れ物をしたせいで、セッション時間を入れ替えてもらったという経緯あり。そんなわけで、自分はほとんど見ることができなかったのが悔やまれます。

RIAことはじめ

3月まで自分一緒にプロジェクトをやっていたhikaru氏に頼んでFlexの紹介セッションをやってもらいました。初スピーカーで緊張気味でしたが、セッション狙い（「Flexで作ったアプリは簡単なのにリッチだ!!」といった部分を伝える）は達成できたんじゃないかな。

おひるごはん

私を含む8人で県民会館から少々歩いたところにあるうどん屋（本当は蕎麦屋なんだけど、最近蕎麦を出していない）「鶴喜」にて。富山の名店。平日と土曜の昼しか開いていないのでなかなか食べに行けない。

Javaのこれまでとこれから

本当は最初にやるはずだったセッション。この日の勉強会の各種セッションの土台となる部分を統括的に。Javaの歴史のおさらいと、最近の方向性を提示して、各セッションで具体的なところを見てもらうというつもりだったのですが。

最近は、システム開発の環境改善には経済的側面をちゃんと考えないとうまくいかないよというのを痛感しているので、そちらの比重が高めにしてみました。

部屋移動

会場の都合で連続して部屋を確保できなかったので部屋移動が入ってしまいました。後半の部屋の方が椅子とか座り心地が良かった。富山県民会館を使うなら7Fの部屋の方がグレードが高いよ！

ライトニングトーク

katzchang氏によるプログラミング言語Ioの話。言語としてなかなか面白そう。

daisuke氏によるメールサーバの管理の話。スパムのリレーが多くて挙句スパムのブラックリストに載せられてしまった！スパム対策どうしよう！といった話題。スパム対策は本当に頭の痛い問題です。

矢野勉氏が飛び入りで１つやってくれました。業務で使うちょっとしたツールもJavaで書いちゃうぜってときに短く楽に書くためのコツみたいな話。潔い割り切りが重要。時間が余って晒し者タイムになったのでjava-jaでのLTの雰囲気とかそんな話も少々。

JavaからScalaへ

keisuken氏のScalaセッション。と見せかけて本題は氏の開発するWeb Flavorだったりしたセッション。手続き型のプログラム言語しかやったことない人にはかなりのデカルチャーだったのではないでしょうか。自分もチャンスがあったらScalaを採用したいなぁ。

やっぱAppletやちゃ

米林正明氏によるセッション。Java SE6 update10のドラッガブルアプレットとかそのあたりの話題。(参考：Java SE6 update10 を使って Applet で遊ぶ！)

これはデモのインパクトが大。会場が沸きました。JavaScript - Applet間での呼出しは実務でも応用が効きそうですね。注目すべき技術の一つでしょう。

なお、タイトルの語尾「～やちゃ」は「～だよ」の富山弁表現。氏は富山の出身だそうで、今回の勉強会もスケジュールの厳しい中駆けつけてくれました。感謝！

懇親会

近くのお店に移動して懇親会。掘りごたつ型の座敷だったんだけど、席移動がしにくいのが難点かな。各所で話が盛り上がっていたのはいいのだけど、話す人が偏ってしまいましたね。

1.5次会

数名はラーメンの富山ブラックの大喜（富山駅前店）に吸い込まれていきました。県外の人は一度食べておくと話のネタになるかもしれない。個人的には、一度だけでいいんじゃないのとも思う。

2次会

白馬館という老舗バー。富山駅前の近くなので、電車やバスなどの人がいる場合には最適。自分は思い切り面が割れているので悪いことはできません。えぇ。

3次会

代行運転を捕まえて凪瀬邸へ。矢野氏は前日からの疲れからか付いた早々に爆睡。もうひとりのメンバーkeisuken氏としばらく話をして就寝。

翌日

朝に二人を送って富山駅へ。お土産を購入。富山の黒作り（イカスミ入りのイカの塩辛）を勧める。関西方面のkeisuken氏を見送った後、東京方面の電車の発射まで時間があったので矢野氏と朝食。話し込んでいたら時間ぎりぎりになってしまった。無事に乗れたようでなにより。

月曜日

気が緩んだのか風邪をひいたらしく、寒気がしてヤバい。夕方に早退して実家で養生。レポートが遅れてすいません。

今週末は富山勉強会#1

凪瀬 — Thu, 06 Nov 2008 01:29:00 GMT

いよいよ今週末土曜日がわんくま同盟富山勉強会 #01です。

場所は富山県民会館です。当日参加も可能ですが、出来るだけ事前登録をお願いします。

10:40 ～ 10:50 わんくまについて
10:50 ～ 11:40 「Javaのこれまでとこれから」凪瀬悠輝Lv2くまー
11:50 ～ 12:20 「RIAことはじめ - Flex-Javaで簡単なアプリを作成してみる -」hikaru
12:20 ～ 13:20 おひるごはん♪
13:20 ～ 14:20 Wicket関連矢野勉
14:20 ～ 14:50 部屋移動
14:50 ～ 15:20 ライトニングトーク

katzchang
daisuke
スピーカー募集中！

15:20 ～ 16:10 「JavaからScalaへ、ScalaからJavaへ(仮)」keisuken
16:20 ～ 17:10 Teeda、Applet関連米林正明
17:40 ～懇親会

わんくま勉強会全般がそうですが、懇親会がメインです！

いろんな人といろんな話ができるのはこうした勉強会の大きなメリットですね。懇親会に参加される方はお店の予約の関係もあるので、できるだけ早く登録をお願いします。

Eclipseのリファクタリング機能を極めるその１

凪瀬 — Mon, 03 Nov 2008 23:49:00 GMT

Eclipseにはリファクタリングという便利な機能があります。このシリーズではその使い方をお送りしたいと思います。

まずは手始めにrename機能からです。

Eclipeのリファクタリングリネーム機能

リファクタリングの初歩としてリネーム（名称変更）が挙げられます。

Eclipse3.4では以下の要素に対してリネームを行うことができます。

型（クラス・インターフェース・列挙型）
メソッド
メソッドの引数
フィールド
ローカル変数
ジェネリクス型パラメータ
列挙
コンパイル単位(.javaファイルのこと)
パッケージ
ソースフォルダ
プロジェクト

Eclipse3.4ではリネームの際にテキストフィールド上で操作を完結することができますが、オプションを指定したい場合は▼をクリックすることでダイアログを開くことができます。

"Open Rename Dialog"を選択します。すると、選択中の要素に合わせたダイアログが表示されます。以下は特殊なオプションの存在する要素についての補足です。

型の場合

型のリネーム機能では、近い名前のフィールド名やメソッド名をリネームさせることができます。 Rename Typeダイアログで"Update similarly named variables and methods"「同名の変数・メソッドも更新する」を選択してください。 "Configure ..."を選択することで、型名のマッチング方法を設定することができます。

"Find exact names only"「完全に一致する名前だけを対象とします」
"Also find embedded names"「語中に埋め込まれた名前も対象とします」
"Also find name suffixes"「語尾が同じものを対象とします」

"Update textual occurrences in comments and strings"
「コメント・文字列中にある型名を更新する」
ではコメントやStringリテラル中にある型名を変更してくれます。ただし、英文を前提にしているのか型名はスペースで区切られていないとうまく識別できません。語と語の間に空白が入らない日本語のような環境下ではうまく機能しないことがあります。

"Update fully qualified names in non-Java text files"
「非Javaのテキストファイル中の完全名を更新する」
では.javaファイル以外のテキストファイル中に現れる、完全名（パッケージ名の記述を省略しないクラス名表記）を更新します。 "File name patterns"で対象となるファイル名を絞り込むことができます。

メソッドの場合

"Keep original method ad delegate to renamed method"
「オリジナルのメソッドを残して名称を変更したメソッドに処理を委譲します」
Adapterパターンなどの実装時に便利です。

フィールドの場合

"Update textual occurrences in comments and strings"
クラスに同じ

"Rename getter: 'getHoge' to 'getPiyo'"
"Rename setter: 'setHoge' to 'setPiyo'"
getter/setterを併せてリネームします

列挙の場合

"Update textual occurrences in comments and strings"
クラスに同じ

コンパイル単位の場合

"Update similarly named variables and methods"
"Update textual occurrences in comments and strings"
"Update fully qualified names in non-Java text files"
クラスに同じ

パッケージの場合

"Rename subpackages"
「サブパッケージも併せてリネームします」

"Update textual occurrences in comments and strings"
"Update fully qualified names in non-Java text files"
クラスに同じ

機械的なリファクタリングの力

いかがでしょうか。これらの変更は、コンパイルと同じく静的に機械的に行われるもので、現在ではかなりの信頼性を持っています。手作業でこういった作業を行う場合、時間がかかることもありますが、ヒューマンエラーによるミスの混入を防げません。その点からしても、これらの機能を使わない手はないでしょう。

過去にはこうした作業はヒューマンエラーによるバグ混入を恐れて、「極力行わないこと」としていたかもしれませんが、機械的に相当の精度で行われると言う前提のもとでは、そのリスクも再評価せねばなりません。

少なくとも、これらの要素の名称変更に対して昔ほどリスクを負わなくなったと言うことは把握しておいてください。名称変更がそれほどリスキーではなくなった今、名称未確定のまま開発を進めることは難しくなくなったということでもあります。

ジェネリックなクラスの階層を遡って適用された具象型を得る

凪瀬 — Wed, 29 Oct 2008 00:50:00 GMT

イレイジャではジェネリクスの何が消えるのかにて親クラスを継承する際に投入しているジェネリクス型パラメータはclassの情報として残っていることを述べました。

これを利用すると、

public class A<X> {

public class B<Y> extends A<Y> {

public class C extends B<String> {

といった継承階層があった場合に、C.classからA.classの<X>にどのような具象型が適用されているのか(上記例ではString型)をリフレクションで取得することができます。

Aの型パラメータのプレースホルダ<X>を取得
Bでsuper-classの型パラメータに渡されたTypeを取得
2のTypeが具象型ではなく型パラメータ<Y>なのでさらにサブクラスを走査
Cでsuper-classの型パラメータに渡されたTypeを取得
B<Y>のYにString型が渡されていることが分かるのでA<X>のXがStringであることが分かる

といった感じです。型階層がいくらあるのか分からないので再帰で処理するとよいでしょう。

サンプルプログラム

/** * 渡された型から継承階層を登って、 * 指定の親の型の指定の名前のジェネリクス型パラメータが * 継承の過程で何型で具現化されているかを走査して返す。 * @param clazz 走査開始する型 * @param targetClass 走査する対象のジェネリクス型パラメータを持つ型。 * 走査開始型の親である必要がある。 * @param targetTypeName 何型で具現化されたを確認したい型パラメータのプレースホルダ名 * @return 具現化された型 */ public static <T> Class<T> getGenericType( Class<?> clazz, Class<?> targetClass, String targetTypeName) { if (!targetClass.isAssignableFrom(clazz)) { throw new IllegalArgumentException( "型" + clazz.getName() + "は、型" + targetClass.getName() + "を継承していません"); } Stack<Class<?>> stack = new Stack<Class<?>>(); while (!targetClass.equals(clazz.getSuperclass())) { stack.push(clazz); clazz = clazz.getSuperclass(); } return getGenericTypeImpl(clazz, targetTypeName, stack); } /** * 型パラメータの具象型取得の実装。再帰処理される。 * @param clazz 現在の走査対象型 * @param targetTypeName 現在の走査対象のジェネリクス型パラメータ名 * @param stack 現在の走査対象型以下の継承階層が積まれたStack * @return 該当型パラメータの具現化された型 */ @SuppressWarnings("unchecked") private static <T> Class<T> getGenericTypeImpl(Class<?> clazz, String targetTypeName, Stack<Class<?>> stack) { TypeVariable<? extends Class<?>>[] superGenTypeAray = clazz.getSuperclass().getTypeParameters(); // 走査対象の型パラメータの名称(Tなど)から宣言のインデックスを取得 int index = 0; boolean existFlag = false; for (TypeVariable<? extends Class<?>> type : superGenTypeAray) { if (targetTypeName.equals(type.getName())) { existFlag = true; break; } index++; } if (!existFlag) { throw new IllegalArgumentException( targetTypeName + "に合致するジェネリクス型パラメータがみつかりません"); } // 走査対象の型パラメータが何型とされているのかを取得 ParameterizedType type = (ParameterizedType) clazz.getGenericSuperclass(); Type y = type.getActualTypeArguments()[index]; // 具象型で継承されている場合 if (y instanceof Class) { return (Class<T>)y; } // ジェネリックパラメータの場合 if (y instanceof TypeVariable) { TypeVariable<Class<?>> tv = (TypeVariable<Class<?>>)y; // 再帰して同名の型パラメータを継承階層を下りながら解決を試みる Class<?> sub = stack.pop(); return getGenericTypeImpl(sub, tv.getName(), stack); } // ジェネリック型パラメータを持つ型の場合 if (y instanceof ParameterizedType) { ParameterizedType pt = (ParameterizedType) y; return (Class<T>) pt.getRawType(); } throw new IllegalArgumentException("予期せぬ型 : " + y.toString() + " (" + y.getClass() + ")"); }

Seasarなど命名規約ベースのDIではリネームに気をつける

凪瀬 — Wed, 22 Oct 2008 09:45:00 GMT

Seasarでは命名規約に則ったクラス名のクラスのインスタンスを、同名のフィールドにインジェクションしてくれる機能があります。

public class SampleService { /** DIコンテナがインジェクションしてくれるフィールド */ public HogeLogic hogeLogic; public void exec() { // メソッド中はインスタンスフィールドにインジェクションされる前提でコードを書く this.hogeLogic.hoge(); } }

これは命名規約を理解して使っている分には便利なのですが、Eclipseのリファクタリング機能などでクラス名をリネームすると突如動かなくなることがあるので注意が必要です。

上記例で、HogeLogicをPiyoLogicにリネームするとしましょう。HogeLogicのクラス名を選択して、Refactor → rename を選択します。すると以下のようなバルーンが表示される(以下はEclipse3.4のスクリーンショット。確か3.2以前ではリネームは必ずダイアログでの入力だったはず) ので新しい名前―ここではPiyoLogicとしましょう―を入力します。

すると、Eclipseのリファクタリング機能でクラス名をリネームすると、参照している箇所を網羅的に探してリネームしてくれるため、プロジェクトの全ソース中でHogeServiceがPiyoServiceに変わります。

この際、クラス名は変更されますが、同名のフィールド名まではリネームしてはくれません。そのため、SampleServiceでのフィールド宣言は以下のようになります。

/** DIコンテナがインジェクションしてくれるフィールド */ public PiyoLogic hogeLogic;

フィールド名が元のままですね。これにより、命名規約違反が生じてうまくインジェクションされなくなります。コンパイルエラーは起きませんが、実行時にインジェクションを期待したフィールドがnull値となり NullPointerExceptionを発生させることになります。

デフォルトのリネーム操作だとこのような問題が起きるのですが、Eclipseにはフィールド名を含めたリネームがサポートされています。リネームの際に▼をクリックし、"Open Rename Dialog"とします。(キーボードショートカットのAlt+Shift+Rも活用しましょう)

"Update similarly named variables and methods"にチェックを入れます。同名の変数とメソッド(getter,setterなど)を更新する、という意味合いですね。そうすると、以下のように変数名も同時にリネームしてくれます。

public class SampleService { /** DIコンテナがインジェクションしてくれるフィールド */ public PiyoLogic piyoLogic; public void exec() { // メソッド中はインスタンスフィールドにインジェクションされる前提でコードを書く this.piyoLogic.hoge(); } }

Seaserなどを利用している場合は、クラス名のリネームの際にはこの点に気を付けて作業しましょう。

イレイジャではジェネリクスの何が消えるのか

凪瀬 — Mon, 13 Oct 2008 20:21:00 GMT

Javaのジェネリクスはコンパイル時に解決され、classファイルになった時にはジェネリクスの型情報は残されていません。そのためイレイジャ（型消去：type erasure）方式と呼ばれます。

と、ひとくちで言っても意味がよく分からないのでちょっと掘り下げてみましょう。

インスタンスからジェネリクスの型情報は拾えない

リフレクションを用いたとしても、インスタンスからジェネリクス型パラメータが何であるかを取得することはできません。

List<String> stringList = new ArrayList<String>();

のような変数stringListがあったとして、ここから<String>を取得するということができないのです。これが消えてしまった部分。

この変数stringListに対する各種操作において、その型の安全はコンパイル時に精査され、実行時にはあくまでObject型引数のメソッドを通したやりとりで動くのです。

クラス宣言に関わるジェネリクス型情報は拾える

しかし、型の宣言に関する部分はリフレクションで拾うことができます。ここが混乱する部分ですね。

親クラスを継承する際に投入しているジェネリクス型パラメータ
インターフェースを実装する際に投入しているジェネリクス型パラメータ
メソッドの引数・戻り値に用いられているジェネリックな型とそこに渡される型パラメータ
フィールドに用いられているジェネリックな型とそこに渡される型パラメータ

といった情報は拾えるわけです。

public class Piyo extends Hoge<String> implements IHoge<String> { private List<String> value; public List<String> get() { return this.value; } public void set(List<String> value) { this.value = value; } }

といったコードがあった場合、リフレクションで親クラスがHoge<String>型であることを拾えます。インターフェースも同等。また、フィールドやメソッドの戻り値・引数がList<String>型であることも拾うことができます。

11/08は富山勉強会

凪瀬 — Tue, 07 Oct 2008 09:18:00 GMT

中さんのところでも告知がでていましたが、わんくま同盟富山勉強会 #01の募集が始まっています。

2008/11/08(土)で場所は富山県民会館です。富山駅近辺ですので近県の方も是非いらしてくださいね。

LT(ライトニングトーク)の登壇者募集中です。発表時間は5分きっかり。こちらはテーマも自由ですよ。

アーキテクチャ選定ではメリットとデメリットを考える

凪瀬 — Thu, 25 Sep 2008 23:16:00 GMT

アルゴリズムであるとか、アーキテクチャというのは、必ずメリットとデメリットがあります。

プログラマは前提条件に合わせてメリットが活き、デメリットは表に出ないように考えアルゴリズムの選定します。アーキテクトがフレームワークやアーキテクチャを選定する時も同等です。

「大規模プロジェクトではどうするか」を考えるより、「大規模にしないためにはどうするか」を考えようというエントリに対し、私はネズミかゾウかではなくて、肥満か筋肉質かだろうと答えたわけですが、さて、では筋肉質なシステムとはどんなシステムか？という話になります。

思うに、筋肉質なシステムというのは、選定したアーキテクチャなり、フレームワークなりのメリットが活き、デメリットが隠れるようになっている、そんなシステムのことではないでしょうか。

だから、それが例えばCOBOLで新規開発という話だったとしても、「過去資産を活用する」というメリットが大きく、その過去資産の活用のための工数がデメリットにならず、過去資産を流用することで未来の保守の工数が嵩むといったデメリットもでない、というなら筋肉質と言えましょう。

通常は、このメリット・デメリットを秤にかけて、相応にメリットが大きいという状況でないといけないわけで、東京海上の例では、本当にデメリットは小さいの？と疑問に思うわけです。

さて、ではJavaのフレームワークの中ではすっかり枯れた技術という評判のStrutsはどうなのでしょうか？Strutsは初出が2001年と古く、近年のAJAXなどの対応を盛り込むにはマッチしないフレームワークだと私は評しています。非同期通信を伴わない、単純なWebシステムで工数を抑えて機能を量産するというなら、それなりにメリットは活きるでしょうし、デメリットは隠れるのではないかと思います。

これはStrutsに限らず、PHPやRubyでの開発でも、状況によってはメリットは活きず、デメリットが表出することになります。そうしたミスマッチな選択をしたプロジェクトは、その無理から脂肪のような無駄なソースが膨らみ、デメリットだらけとなってしまうことでしょう。私が選定するならFlexなどのリッチクライアントとかかなぁ。ユーザ容貌的にそちらの方がマッチして贅肉が少なくなる気がしますね。

内部クラスをリフレクションで扱う場合の注意点

凪瀬 — Mon, 08 Sep 2008 21:24:00 GMT

Javaで一般に内部クラスと呼ばれるものはバリエーションが４つあるのですが、リフレクションでこれらを用いる場合に結構ハマるポイントがあります。

	判別法	外部クラスのインスタンス	コンストラクタ
staticなネストしたクラス	Class#isMemberClass()がtrue かつ、Class#getModifiers()がModifier#isStatic()でtrue	アクセス不可
エンクロージング型内部クラス	Class#isMemberClass()がtrue かつ、Class#getModifiers()がModifier#isStatic()でfalse	外部クラス名.this でアクセス可能	第一引数に暗黙に外部クラスのインスタンスを受け取る
メソッド内で定義されるローカルクラス	Class#isLocalClass()	宣言されたメソッドがstaticなら不可。インスタンスメソッドならば、外部クラス名.this でアクセス可能	インスタンスメソッドで宣言された場合、第一引数に暗黙に外部クラスのインスタンスを受け取る
匿名クラス	Class#isAnonymousClass()	外部クラス名.this でアクセス可能	第一引数に暗黙に外部クラスのインスタンスを受け取る

とあって、staticなネストしたクラスとエンクロージング型内部クラスの判別が面倒臭い。

また、staticなネストしたクラス以外は、暗黙にコンストラクタの第一引数に外部クラスのインスタンスを受け取るのでリフレクションでConstructorを扱う時にはシグネチャに注意。とくに、メソッドで定義するローカルクラスは、宣言がstaticメソッドか、インスタンスメソッドかで違ってくるためClass#getModifiers()の値を確認して丁寧に対応する必要があります。

11/8 わんくま富山勉強会 #1 ～Javaの未来を考える～

凪瀬 — Mon, 01 Sep 2008 20:30:00 GMT

わんくま勉強会の地方開催シリーズ。北陸のエンジニアのみなさん、お待たせしました。

2008年11月8日に「11/8 わんくま富山勉強会 #1」を開催いたします。副題として「Javaの未来を考える」とテーマを設けさせてもらいました。普段仕事でJavaを使っている方々をメインターゲットに、今後の業界動向を展望するセッションで出迎えたいと考えています。

会場は富山県民会館です。 JR富山駅から徒歩10分ほどですので、近県の方もぜひお越しください。

大きな地図で見る

セッション内容などについては、詳細が決まり次第お伝えしますのでお楽しみに！