@Repositoryとproxy

@Repository をクラスに付けると、そのクラスのproxyが作られます。

proxyてなんやねんって話ですが、これは実行時に生成される該当クラスのサブクラスで、他のコンポーネントにインジェクションされるのはこのproxyのインスタンスです。 実際のクラスのインスタンスへはproxyのインスタンスを経由して委譲される仕組みになっています。

このproxyの仕組みには、コンポーネントの利用者がスコープを意識しなくてよくなるという利点があります。

どういうことか、順を追って見ていきましょう。

//※これはSpringではない架空のDIコンテナのコード

@SessionScope
public class Hoge {

    @Inject
    private Fuga fuga;

    public void action() {
        fuga.process();
    }
}

@RequestScope
public class Fuga {
    //フィールドやメソッドの定義は省略
}

//実際には実行時にクラスファイルが生成されるのでソースコードは存在しない
//あくまでもproxyのイメージ
public class FugaProxy extends Fuga {

    private Container container;

    public void process() {
        Fuga component = container.getComponent(Fuga.class);
        component.process();
    }
}

finalメソッドからフィールドを参照したらnullになった理由

当初の問題に戻りましょう。 「 @Respository を付けたクラスの final なメソッドを実行するとインジェクションされたはずのフィールドへアクセスしたときに NullPointerException が発生した」という問題です。

次のコードを見てください。

@Repository
public class Foo {

    @Autowired
    private Bar bar;

    public String method1() {
        return String.format("%s%n%s%n", bar, getClass());
    }

    public final String method2() {
        return String.format("%s%n%s%n", bar, getClass());
    }
}

method1 と method2 はどちらもフィールド bar と自分自身のクラスを文字列にして返しています。 異なる点は method2 は final であるということだけです。

method1 の実行結果はこちら。

com.example.demo.Bar@1db75e25
class com.example.demo.Foo

method2 の実行結果はこちら。

null
class com.example.demo.Foo$$EnhancerBySpringCGLIB$$a65476ff

当初の問題と同じように final な方の method2 では bar が null になっていますね。

ただ、クラス名にも注目してください。 method1 では Foo となっていますが method2 は Foo のproxyになっています。

ここで Foo のproxyがどうなっているのか、再び雰囲気でコードにしてみましょう。

//雰囲気
public class Foo$$EnhancerBySpringCGLIB$$a65476ff extends Foo {

    Container container;

    @Override
    public String method1() {
        Foo component = container.getComponent(Foo.class);
        return component.method1();
    }

    //method2はfinalなのでoverrideできない
}

ご覧の通り method1 はコンテナから実際のインスタンスを取り出して委譲していますが、 method2 は final なため override できずに実際のインスタンスに委譲されることなく実行されてしまいます。

proxyは、コンテナから実際のインスタンスを取り出して委譲するものなので、proxyに対してコンポーネントをインジェクションする意味はありません。 実際、元のクラスでインジェクション対象となっているフィールドはproxyでは null になります。

以上が、proxyが作られるクラスに定義された final メソッドがインジェクション対象のフィールドを参照している場合に NullPointerException になる理由です。

コンストラクタインジェクションとproxy

さて、ここからが私も初めて知った事柄になります。 久しぶりにびっくりした。

次のようにコンストラクタインジェクションしているクラスを考えてみましょう。

@Repository
public class Foo {

    private final Bar bar;

    public Foo(Bar bar) {
        this.bar = Objects.requireNonNull(bar);
    }

    public String method1() {
        return String.format("%s%n%s%n", bar, getClass());
    }

    public final String method2() {
        return String.format("%s%n%s%n", bar, getClass());
    }
}

proxyの雰囲気コードはこんな感じ。

//雰囲気
public class Foo$$EnhancerBySpringCGLIB$$a65476ff extends Foo {

    Container container;

    public Foo$$EnhancerBySpringCGLIB$$a65476ff(Bar bar) {
        super(bar);
    }

    @Override
    public String method1() {
        Foo component = container.getComponent(Foo.class);
        return component.method1();
    }

    //method2はfinalなのでoverrideできない
}

この場合、生成されるproxyのコンストラクタ引数 bar には何が入るのでしょうか？

先に述べた通り、proxyのインジェクション対象フィールドにはインジェクションする意味はありません。 かと言って null を渡すとスーパークラスのコンストラクタで Objects.requireNonNull によって NullPointerException がスローされます。

それではSpringはproxyをインスタンス化するときに何を渡すのでしょうか？

色々とがんばってソースコードを追っかけた末に分かったのですが、コンストラクタを呼ばずにインスタンス化していました。 何を言っているのか分かりませんね？

proxyのインスタンス化にはObjenesisというライブラリの次のクラスが使われていました。 （実際には org.springframework.objenesis にrepackageされています）

• https://github.com/easymock/objenesis/blob/2.6/main/src/main/java/org/objenesis/instantiator/sun/SunReflectionFactoryInstantiator.java

クラスのJavadocに次の記載があります。

Instantiates an object, WITHOUT calling it’s constructor, using internal sun.reflect.ReflectionFactory

お、おう……！ って感じですが、JDKのinternalなクラスを使ってコンストラクタを呼ばずにインスタンス化していました。 だからフィールドが null だった、というわけですね。

コンストラクタ呼ばれないってどういうことだよ……と思いながら SunReflectionFactoryInstantiator を眺めていたら newConstructorForSerialization というメソッド名が出てきて、そういえばシリアライズされたオブジェクトをデシリアライズする時ってコンストラクタ呼ばれないんだっけ、とか雑な記憶で雑に思いました。 とか書いておくと詳しい人がコメントくれるはずです。 他力本願。

まとめ

• DIコンテナにはproxyを経由してスコープを意識せずに使える機能がある
• proxyは実行時にサブクラスを生成して実現するので final メソッドを使うとマズい
• SpringではproxyはJDKのinternalなクラスを使用してコンストラクタ呼び出し無しにインスタンス化される（その結果フィールドが null になる）

こんな感じで、割と真っ黒な黒魔術に辿り着いた感があって楽しかったです。 こざけさん、ありがとう！

018-02-22 22:22:14.298  INFO 25770 --- [  restartedMain] o.s.aop.framework.CglibAopProxy          : Final method [public final java.lang.String com.example.demo.Foo.method2()] cannot get proxied via CGLIB: Calls to this method will NOT be routed to the target instance and might lead to NPEs against uninitialized fields in the proxy instance.

間違いと思われる記述

いくつか間違いがあったので挙げておこうと思います。

//{クラス名}::{メソッド名}の記法でインスタンスのメソッドを参照している
ToIntFunction<String> f = String::length;
int i = f.applyAsInt("foobar");

まとめ

このようにいくつか間違いと思われる記述もありましたが、 これらは前半の章(文法の解説などのまさに入門的な章)に集中していました。

読み進めるにつれてより実践的な内容が増えており、 現場で使える知識を付けることができるのではないでしょうか。

今年の活動

今年は意識的にいろいろ登壇するぞー、と昨年から決めていました。

結果は次の通り。

• Java Day Tokyo 2016でJava EEとWebセキュリティに関するテーマで登壇
• 東京でDoma勉強会を開催してDoma作者の中村さんに初めてお会いした
• Scala関西Summit 2016で登壇
• Spring Day 2016でJava EE(JAX-RS、CDI)とSpring(Spring MVC、Spring Framework)の比較をテーマに登壇
• JJUG CCC 2016 Fallで登壇

登壇以外で言うと、いろふさんと二人でWEB+DB PRESSで「Javaの新定石」の連載をしたのが大きいです。

Java Day TokyoとSpring Dayの登壇、それからWEB+DB PRESSの連載は会社名を出して行いましたが、 出張扱いで交通費も完全に出して貰ったし、これらの社外活動も評価して貰えているので、弊社は良い中小SIerだなー、と思いました。

それから、これはネタ以外のなにものでもないけれど、 セミコロンレスJavaで戻り値のあるメソッドを実装してのけました 。 この時ばかりは、自分を天才かと思いました。

来年に向けて

私のGitHubリポジトリのアクティビティログには顕著に現れていますが、 最近は完全にSpringへ傾倒しています。

今年は表面の美味しいところをぺろぺろした感じなので、 来年は奥まで覗いてﾁｮｯﾄﾃﾞｷﾙになろうと思っています。

まだまだ足りておらず飢えてもいるので、いろいろ殴って強くなりたいです。

5周年

結婚 してからまる5年が経ちました。 特に激しいケンカもなく、のんびりと、ゆる〜く夫婦をやっております。

距離感

妻も私と同じくプログラマです。 だけど私と異なり、家でまでコードを書くようなプログラマではありません。 たぶん、まったくの別業界の人よりは私のようなプログラマに理解があり、それでいて私の趣味には干渉しないぐらいの距離感が心地良く感じています。

週末は二人で出かけることが多いですが、「今週末は勉強会に行きたい！」と言っても「良いよ」と返してくれて、別々に行動することもままあります。 もちろん、妻が友達と遊びたいと言ってきた場合は私も了承するので、お互いを縛ることなく楽しく過ごせています。

日常

朝は私が朝ごはんの準備をしている間に妻がお弁当の準備をしてくれます。 夜は先に帰った方が晩ごはんの準備をします。

仕事が終わって帰るときはLINEします。 たまに無意味なスタンプの応酬になります。 気付いたら最寄駅です。

寝るまでの間はお茶を飲みながらお互い好きに過ごします。 大抵、私はPCでコード書いたりTwitterしたりギター弾いたり、妻はスマホをいじったりテレビを見たりしています。 好きなことをしつつ、ときどき会話して、また好きなことをして、妻がドライヤーで髪を乾かし、また会話して。

お互いに別々のことをしていても同じ空間に居るのが大切で、結婚というのはそういうものなのかもなー、と思っています。

しみじみ

家に帰ってるだけじゃなくて人にも帰ってるのかもなー

— うらがみ⛄️ (@backpaper0) 2016年1月29日

最近のデート

京都水族館、楽しかった。

うらがみさん(@backpaper0)が投稿した写真 - 2016 11月 23 3:40午後 PST

まとめ

ただただ日常と、普段から思っていることを書いただけで、大して惚気られなかった気もしますがいかがでしたか？

結婚は人によって合う・合わないがあると思うので無条件ではオススメはしませんが、 私は結婚して良かったなーと思うことはあっても逆は一度もありません。

いつもそばに居てくれて、妻には感謝しているし、愛しています。

明日は @susumuis さんです。

到達不能文

例えば while(false) { ... } とした時、この while ブロック内の文は絶対に実行されません。 このように絶対に実行されない文を 到達不能 と表現し、到達不能な文がある場合はコンパイルエラーになります。

次のような内容で Sample1.java を作成して javac してみてください。

public class Sample1 {
    public void whileSample() {
        while(false) {
            System.out.println("到達不能！");
        }
    }
}

次のようなエラーになります。

Sample1.java:3: エラー: この文に制御が移ることはありません
        while(false) {
                     ^
エラー1個

for 文でも同じ事ができます。

public class Sample2 {
    public void forSample() {
        for(;false;) {
            System.out.println("到達不能！");
        }
    }
}

Sample2.java:3: エラー: この文に制御が移ることはありません
        for(;false;) {
                     ^
エラー1個

try 文はエラーメッセージは違いますが、次のようコードは到達不能な文を含むのでコンパイルエラーになります。

public class Sample3 {
    public void trySample() {
        try {
            System.out.println("到達可能");
        } catch(RuntimeException e) {
            System.out.println("到達可能");
        } catch(IllegalArgumentException e) {
            System.out.println("到達不能！");
        }
    }
}

Sample3.java:7: エラー: 例外IllegalArgumentExceptionはすでに捕捉されています
        } catch(IllegalArgumentException e) {
          ^
エラー1個

特別扱いの if

ここまで while 、 for 、 try の到達不能な文を含むコードがコンパイルエラーになる例を見てきました。 if 文でも同じような事ができるかと思いきや、次のコードはコンパイルできてしまいます。

public class Sample4 {
    public void ifSample() {
        if(false) {
            System.out.println("到達不能！");
        }
    }
}

到達不能な文を含んだ if 文はどのようにコンパイルされたのか、 javap -c Sample4 して確認してみましょう。

Compiled from "Sample4.java"
public class Sample4 {
  public Sample4();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void ifSample();
    Code:
       0: return
}

ご覧の通り、 if 文が綺麗さっぱり消えていますね。

では、 if の条件式を true に変えてコンパイルして javap してみましょう。 （クラス名などは少し変えてあります）

Compiled from "Sample5.java"
public class Sample5 {
  public Sample5();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void ifSample();
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #3                  // String 到達可能
       5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

if 文の中身はありますが、条件を評価している部分がなくなりました。

if がこのように特別扱いになっているのは、次のようなコードを書けるようにするためです。

static final boolean DEBUG = true;

void sample() {
    if(DEBUG) { System.out.println("logging"); }
}

先述の特徴があるので、定数 DEBUG が true ならロギングされるけども、 false ならロギングのコードがクラスファイルからも消える、という感じです。

return を書かずに戻り値のあるメソッドを定義する

return 文にはどうしてもセミコロンを書く必要があります。 それが故にセミコロンレスJavaでは戻り値のあるメソッドを定義することはできないと考えられていました。

私も「どのようにすればセミコロンを省略して return が書けるのか」と考えては挫折を繰り返してきましたが、 あるとき「セミコロンを省略して return が書けないなら、そもそも return を書かなければ良いのでは」と発想の転換をしてみました。

前半で述べた通り、到達不能な文を含むとコンパイルエラーになります。 逆に考えると、無限ループは到達可能なのでコンパイルを通るし、無限ループの後ろは到達不能なので何を書いてもコンパイルエラーになる、ということですね。

while(true) {
    //到達可能
}
//到達不能

これにより冒頭に記載したツイートの通り、セミコロンを書かずに戻り値のあるメソッドを定義できました。

public class Semicolonless {

    String get() {
        while (true) {
        }
    }
}

ちなみにセミコロンはともかく、 return を書かずに戻り値のあるメソッドを定義する方法としては例外を投げるというのもあります。 （例えば Thread.destroy() ）

戻り値のあるメソッドに return 文なんて要らんかったんや！！！

まとめ

• 一見不可能に思えることでも考え方を変えることで解決する場合がある
• とはいえ解決したところで役に立たないものもある

参考

• 前半に記載した到達不能コードたち
• Java Language Specification 14.21. Unreachable Statements
• 戻ってくるようになりました

GitHubで毎日草生やし続ける運動とは

GitHubはコミットしたりプルリクするとプロフィールページのタイルっぽいやつが緑になります。 緑になるから「草を生やす」って比喩してるんですけど、それを毎日続けて緑で埋め尽くそうというものです。

進捗

7月最後の週ぐらいに草だらけになりました。

それからも毎日草生やしてたので400日ぐらいは継続できていると思います。

なぜやろうと思ったか

三十路になって「これからもコードを書いていられるのだろうか？(環境というよりは自分のモチベーション的な意味で)」と思うようになりました。 なので好きかどうか自分自身を試そうかなー、と。

やってみて得たもの

やる前に思ってたよりもずっと楽しんで続けられたので、やっぱり自分はコード書くの好きなんだな、と思えました。これは嬉しい。

あと、大したコードは書けてないですが、サンプルやらビルドスクリプトが溜まってきて何かと役立っています。

なぜやめようと思ったか

「継続」を目的としていたので、書きたいコードが思いつかない日はREADME.mdを修正するといったセコい草もたまには生やしていましたが、もうそうまでして草生やすのは面倒に思えてきました。

それに、読書のような草が生えない活動にももっと時間を使いたいなーと思い始めました。

当初の目標であった一年は継続できたので、やめるのにも未練は無いですし。 (でもなんか気持ちの整理的にやめることは記しておきたくてこのエントリを書いてる)

まとめ

• コード書くのが好きだと再確認できて個人的には意義がある試みでした
• 草生やし運動は人によって合う・合わないがあるので特別おすすめはしません
• 一年後、プロフィールページが不毛の地と化していたら嘲笑ってください

変遷

新人の頃の☃「private？メソッド？というのがあるのか。ふむ。ふむ……？」

新人ではなくなったが若手の頃の☃「メソッドが大きくなってきたな。privateメソッドで分割だ！」

若手とは言えなくなった頃の☃「privateメソッドのテストコードってどう書いたら良いんだ？リフレクションか？」

2、3年前の☃「privateメソッドは共通処理を切り出すためのもの。呼び出し元のpublicメソッドのテストコードで担保される」

最近の☃「privateメソッド スベテ コロス！！！」

解説

新人の頃は割愛。

次の若手の頃の話は、これは大きいメソッドを単にぶつ切りにして満足しちゃってた感じ。 臭いものに蓋してるだけで何の解決にもなっていませんでしたね、今から思うと。

それからprivateメソッドのテストコードについて悩みました。 どうすれば良いんだ？と。 悩んだ挙句protectedにしちゃたりしてましたが、これも誤魔化しですね。

で、しばらくして、呼び出し元のテストで担保できるじゃろ、と思うようになりました。 この頃にprivateメソッドは複数のpublicメソッドに共通する処理を切り出すものだ、と考えるようになったのでした。 逆に言うと、publicメソッドの一部を共通化する以外の目的でのprivateメソッド導入はダメだと考えるようになりました。

そんでもって最近は、なるべくprivateメソッドは導入したくないと思っています。

個人的にはprivateメソッドを導入する時点で、これ他のクラスのpublicメソッドなのがあるべき姿かも？と考えるようにしてる。

— うらがみ⛄ (@backpaper0) 2016年9月4日

年々、小クラス主義になってるのかなー。 みたいな。

まとめ

冒頭で記載したエントリでは、

結局のところ、privateメソッドの詳細に踏み込んだテストが必要になった時は、設計に何か問題がある可能性が高いということなのだと思う。

と書かれていましたが、私はprivateメソッドを導入しようと思ったタイミングで設計に問題があるのでは？と疑ってみるようにしています。

スライド

私のスライドはこちら。 2本、話させて頂きました。 Domaの主要な機能を私なりに紹介した発表と、ドメインクラスで型最高！という発表です。

• Domaの紹介
• ドメインクラスの話

がくぞさんのスライドはこちら。 collect検索の活用方法、なるほど感すごかったです。 真似させてもらいます！

• とあるDoma2の使い方

そして、中村さんのスライドはこちら。 Doma開発のスタンス、我々ユーザーとの向き合い方に感動しました！！

• Domaの開発で大切にしている10のこと

「LTやってよ！」ってさらっと無茶振りしたのに見事に応えてくれた 多田さん と やんくさん もありがとうございました！

• Doma2とMVC1.0でJava EE Webアプリを作ろう！
• Doma2 with Kotlin

他の方々のブログ、Togetterなど

• 「Doma勉強会 in 東京」に行ってきました。 - シュンツのつまづき日記
• Doma勉強会 in 東京に行ってきた #doma_tokyo - Splash of waters - 2nd. Season
• 【7/9(土)】Doma勉強会 in 東京でLTしてきました #doma_tokyo - Javaプログラマーのはしくれダイアリー
• 【7/9(土)】Doma勉強会 in 東京 - Togetterまとめ
• Doma勉強会 in 東京に行ってきました　#doma_tokyo #eventdots - Chonaso’s Commentary
• 【7/9(土)】Doma勉強会 in 東京 に参加してきた - てんてんのぶろぐ

TLへのリアクション

内容については、他の方々のブログにお任せするとして、ここからは当日のTLから幾つかのツイートをピックアップして、リアクションしたいと思います。

どこかにテンプレート的なものがあるらしい? > build.gradle #doma_tokyo

— 寝起き (@nashcft) 2016年7月9日

これです！

• https://github.com/domaframework/simple-boilerplate

Dialectって主にページネーションの方言を吸収するのか。offsetやらlimitやら。 #doma_tokyo #eventdots

— 多田真敏(MasatoshiTada) (@suke_masa) 2016年7月9日

通常のSELECT文をページネーションするクエリや、 悲観排他するクエリに変換する際にRDBMSの方言を吸収するためのものですね。

ページネーションはH2なら offset と limit を使うけど、Oracleなら rownum を使うし、悲観排他はOracleなら for update を使うけど、SQLServerなら with(updlock) を使う、といった感じです。 この辺をDomaの中で吸収してくれるのが Dialect です。

ページネーションとかはSelectOptionsとかの話かなhttps://t.co/PETWtejqLi#doma_tokyo #eventdots

— やんく (@yy_yank) 2016年7月9日

そうです。 Domaは SelectOptions で offset と limit を指定する事ができます。 他にも悲観排他、それからカウント取得なんかの指定もできます。

• http://doma.readthedocs.io/ja/stable/query/select/#id11

#doma_tokyo NetBeansでは...らしい。（私はMavenでビルド定義して使ってる）

— Den (@den2sn) 2016年7月9日

これは私の誤りのようです。 Mavenプロジェクトなのか、Gradleプロジェクトなのか、そういった違いにもよるのかも知れませんが、少なくともMavenプロジェクトだと何も不都合なく使えるようです。 NetBeans、ごめんなさい。

アクセサいらんのか#doma_tokyo #eventdots

— やんく (@yy_yank) 2016年7月9日

Domaはエンティティのフィールドを直接見に行くのでアクセサメソッドは不要です。

エンティティリスナーでcreate_user、create_dateを設定したいという場合には非常に便利そう。
共通項目クラスとかを用意する必要はありそうだけど。 #doma_tokyo #eventdots

— Junki Yamada（シュンツ） (@glory_of) 2016年7月9日

仰る通り、共通項目だけを持つ基底クラスとなるエンティティを作る必要があります。 基底クラスがあればエンティティリスナーは1つで良いので、楽といえば楽です。

これは後日、サンプルを作ろうと思います。 (私のGitHubリポジトリを漁ったら既にあるかも知れませんが)

Stream にした場合はページングはやってくれるのかな？ #doma_tokyo

— いとうちひろ(Chihiro Ito) (@chiroito) 2016年7月9日

ページネーションは SelectOptions の offset と limit で指定します。 Stream 検索はあくまでも ResultSet.next してエンティティにマッピングする処理を Stream で表現しているだけです。

Streamを返す版はリソース忘れが無いようにそのままだとコンパイル時に警告を出してくれます。close処理を書いたら心を込めてアノテーションつけると警告を外せます。 #doma_tokyo

— がくぞ (@gakuzzzz) 2016年7月9日

Stream を返すためではなく、他の事に心を込めような！！！

……と、冗談はさておき、元々はSpring Batchの ItemReader では ResultSet.next がメソッドをまたぐ必要があるため、それに対応しやすいように入れられた機能です。 通常は使う機会は無いと思います。

これも後日サンプルを書いてみようと思います。

RomaをSpringで使う場合、Spring Bootしか選択肢ないのかな？
Boot以外では使えたりしないかな？#doma_tokyo #eventdots

— Takafumi Iju (@ijufumi_0810) 2016年7月9日

Spring BootではないSpringでも使えます。 実装には doma-spring-boot-autoconfigure が参考になると思います。

Domaが必要とするのは DataSource だけですので、SpringでもJava EEでもJava SEでも、基本的にどこでも使えます。

ローカルトランザクション、Java SE環境で使えるのか#doma_tokyo #eventdots

— やんく (@yy_yank) 2016年7月9日

使えます。 やってる事は単純で Connection.setAutoCommit と Connection.commit と Connection.rollback を組み合わせてトランザクションを行っているだけです。 あとは ThreadLocal を利用してトランザクションの期間中 Connection をスレッドに紐付けています。

LocalTransactionDataSource まわりのコードは小さいので、読んでみるのも楽しいですよ！

今って[at]Transactionalアノテーションサポートしてる？ #doma_tokyo

— Ktz (@ktz_alias) 2016年7月9日

@Transactional はJava EEやSpringといったコンテナの機能で、Domaはサポートしていません。 Domaの範囲からは逸脱すると私は考えます。

とはいえ、例えばGuiceのような軽量コンテナであってもインターセプタの機能を有しているので、 Domaのローカルトランザクションと組み合わせて宣言的トランザクション機能を自作することは可能です。

これも後日サンプルをGuiceとDomaで書いてみますね。

こんな感じで検索すればSQLも引っ掛けられる（STS） #doma_tokyo #eventdots pic.twitter.com/r2US1mwupJ

— Junki Yamada（シュンツ） (@glory_of) 2016年7月9日

シュンツさん、ありがとうございます！！！

「エンティティをDAO内で定義したい」は比較的実装しやすいかもしれません。すでにドメインクラスはネストし
て定義できるようになっていますし。 #doma_tokyo #eventdots

— toshihiro nakamura (@nakamura_to) 2016年7月9日

ソッコーで実装されててわろた。

• https://github.com/domaframework/doma/pull/159

「主キー検索クエリは自動で組み立てたい」は実装自体は簡単。ポリシーとして整合性を保てるか？アノテーションの書き方をどうするか？などが問題になりそうです。#doma_tokyo #eventdots

— toshihiro nakamura (@nakamura_to) 2016年7月9日

ですね、よくわかります。 (なのでわがまま言うつもりはありません)

社員ID,名前、住所、役職とか、これをstringではなく、ドメインクラスにしていくと、クラス数爆発しそう。線引きはどうするんだろ。 #doma_tokyo #eventdots

— まめぴか＠ (@mame_pika) 2016年7月9日

確かに、ドメインクラスを推進するとクラス数は多くなりますが、型の恩恵を受けられるメリットの方が大きいと私は判断しています。

ドメインクラスのgetValueをアプリケーションで呼ばない場合、プレゼンテーション層に値を渡す場合はどうすればいいんだろ？
toStringでvalueを返せば良いのかな？#doma_tokyo #eventdots

— Takafumi Iju (@ijufumi_0810) 2016年7月9日

フレームワークや共通部品のような抽象的な層なら getValue へのアクセスを許可します。 テンプレートにドメインクラスを渡す場合はコンバータを書きます(例えばJAXBの XmlAdapter )。 その際、コンバータには getValue へのアクセスを許可します。

domaのコミュニティ素敵だなあ #doma_tokyo

— 寝起き (@nashcft) 2016年7月9日

ありがとうございます。 本当に嬉しいお言葉です。 イベントを開催して良かった。

蛇足：DDDとの対比(個人的な見解)

ドメインクラスという名前のせいか、DDDに関係するのかな？といったツイートを見かけた事がありますが、DomaはDDD用のフレームワークではありません。 しかし、DDDで語られる各要素がDomaで言えば何なのかを考える事はできます。

個人的には次のように考えています。

• Domaの「テーブルと1対1にマッピングするエンティティ」は、DDDの「エンティティ」に相当する
• Domaの「検索結果にマッピングするエンティティ」と「ドメインクラス」は、DDDの「値オブジェクト」に相当する

懇親会について

今回、懇親会の企画はしていたのですが、参加者を募集しませんでした。 これは、本当に私の我儘でして、中村さん、がくぞさんと私自身がたくさん話したい！と強く思っていたので、広く募集はせずにスタッフと最後まで残って会場の現状復帰に付き合ってくれた方々数名だけとさせて頂きました。

我儘を通した甲斐があって、楽しい夕食の時間を過ごさせて頂きました。

イベント会場であるdotsについて

dots. のイベントスペース、おしゃで綺麗で木の床があって受付にお姉さんがいてかなり良い！！！！！#eventdots

— さらちむ (@syobochim) 2016年7月9日

ほんまそれ。

最高でした！ 勉強会を開催したい方には、会場候補におすすめします！

• dots. [ドッツ] - IT勉強会・セミナーなどのイベント情報サイト

謝辞

このイベントを開催しようと思ったきっかけは、春に東京へ遊びに行った際、一緒に晩御飯を食べてくれる人を募集したらがくぞさんが来てくださったところから始まりました。 がくぞさんが「一緒にやりましょう」と言ってくださったので中村さんにもお声がけする勇気が出ました。 がくぞさん、本当にありがとうございました！

同じく、その晩御飯の席に参加してくださっており、会場としてdotsを挙げてくださった とーますさん にも感謝です！ dotsに関する事のサポートや、懇親会のお店の手配をしてくださり、ありがたかったです。 晩御飯、美味しかったー！

それから、運営の手伝いを買って出てくださった多田さん、やんくさん、ありがとうございました！ 無茶振りのLTにも応えてくださり、イベントがより華やかになりました！

そして、中村さん、突然お声がけしたにも関わらず登壇を快く引き受けてくださってありがとうございました！ ずっと以前からお会いしたくて、でもきっかけが無くて、がくぞさんのおかげで勇気を出せて、お声がけして、ようやくお会いできました。 本当に、本当に嬉しかったです！！！

あと、友人(と表現させてください)の しょぼちむ、 うがさん、 てんてんさん、 ちっひー、 はすぬまさん、 @suzukijさん、 Denさん、 まめぴー、来てくださってありがとうございました！ 中村さんの前での発表はこれでもか！！！ってぐらい緊張していたけど、みんなが居ると思えばこそ最後まで発表できた気がします。

シュンツさん、来てくださってありがとうございました！ 参加登録者を見て、密かに「お会いできる！」とワクワクしていました。 お会いできて嬉しかったです！

最後になりますが、参加してくださった皆さん、本当にありがとうございました！ 皆さんのおかげでイベントが賑やかになり、楽しく過ごす事ができました。

本当に楽しい、夢のような1日でした。

みんなで撮った集合写真は、MBPのデスクトップを飾っています。

スライドめくるやついいなー

いろんな人が発表しているのを見ていると、なんかリモコン的なやつとか指輪っぽいやつでリモートでスライドめくってて「いいなーアレ」と思っていました。

で、自分も発表する時に使いたいなと思ったんですけど、スマホがリモコン的に使えそうだし操作はページ送りできたら良いだけだし作るかー、と。

作ってみた

• https://github.com/backpaper0/slider

ざっくり言うと、Webアプリになっていまして、スマホのブラウザでページを開くとWebSocketで通信を開始し、コマンドを送ってページ送りを行っています。

使い方と仕組み

使い方と共にもうちょい詳しく書きます。

まずコードを clone して、ビルドします。

git clone https://github.com/backpaper0/slider.git

cd slider

gradlew build

すると build/libs/slider.jar が出力されます。

スライドを表示する端末でWebアプリを起動します。

java -jar build/libs/slider.jar

なお、サーバーにはUndertowを使っています。 また、mainメソッドの起動にはSpringBootを使っています。

Webアプリが起動するとスマホのブラウザからWebページを開く必要があるのですが、そのために私はスマホでテザリングをしています。 テザリングをして、 ipconfig とか ifconfig で端末のIPアドレスを確認したら http://<ipaddress>:8080/ へスマホでアクセスします。

画面はこんな感じ。

Left と Right でそれぞれ左・右にページを送ります。 その際、スクリーンショットを撮ってブラウザに送ります。 スクリーンショットは Screenshot ボタンでも取得できます。 そして Presentation ですが、これは私が利用している remark というスライドツールのプレゼンテーションモードを切り替えるために使います。

これらの実現方法ですが、まず Screenshot や Left のボタンを押すとWebSocketでサーバーにコマンドを送ります。 コマンドと言っても SCREENSHOT や LEFT といった単純な文字列です。

サーバーではコマンドを受け取ると Robotクラス を利用して スクリーンショットを撮ったり 、 「左ボタンを押す」というシステム入力イベントを発生させたり します。 これでスライドのページ送りができました。 なお、スクリーンショットはBase64エンコードしてData URIにしてブラウザに送っています。 ブラウザ側ではそれをそのままCanvasに書き出しています。

欲しいものは作ればいいや

仕組みとしては以上でして、まあ説明してみると大したことはしていないんですが、これまでプライベートコーディングではフレームワークを試したりサンプルコードばかり書き捨てていたので、改めて「欲しいと思ったものを自分でも作れるもんだなー」としみじみ思いました。 欲しけりゃ作ろ、と思うようになってきたのは、この数年で出会った何人かのエンジニアのお陰です。 名前を出すのは照れくさいので出しませんが、本当に尊敬しています。

まとめ

• 作ってはみたものの、使う機会を逃しており今回が初の実践でしたが、なかなか上手く行って良かった！
• 何人かの方に気付いて貰えて嬉しかった！(「機会があったら使わせて欲しい」とまで言ってくれた方も居た！)

使いながらもっと便利になるようにちまちまメンテしたい所存です。

Integerのキャッシュ

int がボクシングされると java.lang.Integer になりますが、このとき Integer.valueOf(int) が使われます。 このことは次のようなボクシングされるコードを書いてコンパイルしてからjavapすればよく分かります。

public class IntBoxingSample {
    public Integer boxing(int i) {
        return i;
    }
}

javapしてみた結果は次の通り。

Compiled from "IntBoxingSample.java"
public class IntBoxingSample {
  public IntBoxingSample();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public java.lang.Integer boxing(int);
    Code:
       0: iload_1
       1: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
       4: areturn
}

で、この Integer.valueOf(int) ですが、 -128 から 127 までの範囲はキャッシュされます。

このことは 言語仕様の5.1.7 や Integer.valueOf(int)のJavadoc に書かれています。

でもって、OpenJDKのコードを見た感じ、 java.lang.Integer.IntegerCache.high というシステムプロパティでキャッシュする範囲を変更できそうです。

• Integer.valueOf(int)のコード
• Integerインスタンスをキャッシュする範囲を決定しているstaticイニシャライザ

というわけで次のようなコードを書いてコンパイルして普通に実行すると false と表示されますが、 -Djava.lang.Integer.IntegerCache.high=1000 という風にシステムプロパティを設定して実行すると true と表示されます。

public class Sample {
    public static void main(String[] args) {
        Integer a = 1000;
        Integer b = 1000;
        System.out.println(a == b);
    }
}

実行結果は次の通り。

% java Sample
false
% java -Djava.lang.Integer.IntegerCache.high=1000 Sample
true

他のプリミティブも見てみた

Byte 、 Short 、 Long は Integer と同じく -128 から 127 までキャッシュされていました。 ただしキャッシュの範囲は変更できません。

• Byte.valueOf(byte)のコード と Byteのキャッシュ構築コード
• Short.valueOf(short)のコード と Shortのキャッシュ構築コード
• Long.valueOf(long)のコード と Longのキャッシュ構築コード

それから Character は 0 から 127 までキャッシュされていました。 ASCII文字コードの NUL から DEL ですね。

• Character.valueOf(char)のコード と Characterのキャッシュ構築コード

Boolean は定数 TRUE と FALSE のどちらかを返すようになっています。

• Boolean.valueOf(boolean)のコード

最後に Float と Double ですが、どちらもキャッシュせず常にインスタンス化するようになっていました。 浮動小数点数なので -128.0 から 127.0 の間にも膨大な量のインスタンスを生成し得るので、まあ、そりゃキャッシュしないか、という感じ。

• Float.valueOf(float)のコード
• Double.valueOf(double)のコード

まとめ

以上のように普段は意識しないような部分でキャッシュしておりパフォーマンス向上を図っていたりしています。 こういったJDKの努力に感謝しつつ、今後も意識せずにコーディングしようと思います。

ハンズオンの概要

Acroquest Technology社が業務で収集した実データをベースにした大量のデータを使ってLogstash/Elasticsearch/Kibanaのインストールから入門的な操作を行いました。

感想

レベル的には先述の通り、入門！って感じでしたが、丁寧な資料や実データをもとにして手を動かしたのもあって次の学習ステップを想像しやすくて良かったです。

個人的にはElasticsearchには興味があったんだけど、 LogstashとかKibanaとかナニモノなのかよく分からないし、 興味はあるけど自分のリソース注ぎ込みまくるほど(当時は)優先順位は高くなかったので、 そういった意味でも触れる機会を得られて助かりました。

その他

ステッカー、一通りもらいました！

わーい #elastichandson pic.twitter.com/Apm0Oxdrgb

— うらがみ (@backpaper0) 2016年3月18日

素晴らしい！！！(いろんな意味で)

きつねさんのアイデアを元に、

• 数値演算子を使わなくて済むように Random.nextInt を使用
• new演算子を使わないためにstaticファクトリーメソッドがある SecureRandom を使用

といった事に気をつけて次のようなコードにしました。

//これはセミコロンを書いて良い普通のJava

//これで1〜100のIntStreamが手に入る
SecureRandom r = SecureRandom.getInstanceStrong();
IntStream stream = IntStream.generate(() -> r.nextInt(101))
                            .distinct().limit(101)
                            .sorted().skip(1);

ちなみに、私が考えついたのは次のようなコードでした。

//これはセミコロンを書いて良い普通のJava
Stream.of((ArrayList) Collectors.toList().supplier().get())
      .peek(list -> list.add(BigInteger.ONE))
      .map(list -> IntStream.generate(() ->
         Stream.of((BigInteger) list.get(0))
               .peek(a -> list.remove(0))
               .peek(a -> list.add(a.add(BigInteger.ONE)))
               .findFirst().get().intValue()))
      .findFirst().get();

簡単に言うと ArrayList から値を取り出して返し、その値に1足して、また ArrayList に格納する、を繰り返しています。

ArrayList の生成には Collectors.toList で返される Collector の supplier を利用しました。 ぶっちゃけ Collectors.toList の実装に依存しており美しくないですね。

また、記号を抑えるためにraw型を使用していますが、そのせいでキャストが多発しており、これも美しくないです。

その点、きつねさんが提案してくれた方法はコードが美しく、より狂気があふれており素晴らしい！！！

というわけで、セミコロンなどレスJavaで書いたFizzBuzzは次のようになりました。

public class SemicolonlessFizzBuzz {

    public static void main(String... args) throws Exception {
        if (java.util.stream.Stream
            .of(java.security.SecureRandom.getInstanceStrong())
            .map(r -> java.util.stream.IntStream
                .generate(() -> r.nextInt(101))
                .distinct().limit(101).sorted().skip(1)
                .mapToObj(i -> java.util.Optional.of(java.math.BigInteger.valueOf(i)))
                .map(i -> i.filter(a -> a.mod(java.math.BigInteger.valueOf(15))
                    .equals(java.math.BigInteger.ZERO)).map(a ->
                                    String.valueOf((char) 0x46)
                            .concat(String.valueOf((char) 0x69))
                            .concat(String.valueOf((char) 0x7a))
                            .concat(String.valueOf((char) 0x7a))
                            .concat(String.valueOf((char) 0x42))
                            .concat(String.valueOf((char) 0x75))
                            .concat(String.valueOf((char) 0x7a))
                            .concat(String.valueOf((char) 0x7a)))
         .orElseGet(() -> i.filter(a -> a.mod(java.math.BigInteger.valueOf(3))
                    .equals(java.math.BigInteger.ZERO)).map(a ->
                                    String.valueOf((char) 0x46)
                            .concat(String.valueOf((char) 0x69))
                            .concat(String.valueOf((char) 0x7a))
                            .concat(String.valueOf((char) 0x7a)))
         .orElseGet(() -> i.filter(a -> a.mod(java.math.BigInteger.valueOf(5))
                    .equals(java.math.BigInteger.ZERO)).map(a ->
                                    String.valueOf((char) 0x42)
                            .concat(String.valueOf((char) 0x75))
                            .concat(String.valueOf((char) 0x7a))
                            .concat(String.valueOf((char) 0x7a)))
                .orElseGet(() -> i.get().toString()))))
            .collect(java.util.stream.Collectors.joining(String.valueOf((char) 0x20))))
            .peek(fizzbuzz -> System.out.println(fizzbuzz))
            .count() > 0) {}
    }
}

レガシーセミコロンレスJavaにおけるenumの制限

Java言語ではenumにメソッドを生やす事ができます。

//これはセミコロンを付けても良いありふれた普通のJavaコード
public enum Hoge {
    FOO, BAR, BAZ;

    public void println() {
        System.out.println(name());
    }
}

しかしメソッドを定義するためには一番最後に宣言した列挙定数(上記の例でいうと BAZ )の後ろにセミコロンをつける必要があります。

これは回避できない制約なのでセミコロンレスJavaではenumにメソッドは生やせませんでした。

セミコロンレスJava 8におけるenumの新機能

しかし、Java 8でインターフェースにデフォルトメソッドを持てるようになり、 その副次効果でセミコロンレスJava 8ではenumにメソッドを生やす事が出来るようになりました。

手順は簡単で、デフォルトメソッドを定義したインターフェースを用意してenumでそれをimplementsするだけです。

コード例を示します。

public enum Hoge implements Fuga {
   FOO, BAR, BAZ
}

public interface Fuga {
    default void println() {
        if (System.out.printf("%s%n", ((Hoge) this).name()) != null) {}
    }
}

enumの列挙定数や他のメソッドにアクセスしたい場合はキャストすればOKです。

まとめ

• enumにメソッドを生やせるようになり、ますますセミコロンレスJavaが便利に！

JAX-RSネタで登壇してきた

GH-1のタイポっぽいけどGlassFishっぽくて良いな！ pic.twitter.com/jfu08S7JMW

— うらがみ (@backpaper0) 2015, 11月 28

• http://www.java-users.jp/?page_id=2064#AB-1

というわけで登壇させて頂きました。

• JAX-RS入門および実践

ペース配分が甘くて最後のテストコードのパートをまるごと省略してしまい、聴講してくださった皆様には大変申し訳なく思っています。 おそらく関Javaで再演しますが、その際はしっかり最後まで話せるよう練習しておきます。

また、懇親会で「物足りなかった」というご意見を頂きました。 確かに、できる限りJAX-RSをご存知ない方にもJAX-RSを知って頂きたく、最大公約数的な内容にしたので物足りないと感じた方はいらっしゃるだろうなと思いました。

ですので次(JJUG CCCとは限りませんが)はもうちょっと濃い目の話しをしたいなと思っています。

私のセッションを選んでくださった聴講者の皆様、私のCfPを選んでくださったJJUGスタッフの皆様、資料レビューに付き合ってくれたほげメン・やんくさん、本当にありがとうございました！

まーやさん、たろうさんのコミュニティセッションでお話してきた

• http://www.java-users.jp/?page_id=2064#EF-7

関Javaというコミュニティのスタッフをやっているという事でお声がけ頂いてお話してきました。

内容についてはまーやさんが素敵なレポートを書き上げてくださいました！

• 2015年11月28日JJUG　CCC　参加きろく～登壇編～ | hotchpotch

ここでは時間の都合で話せなかった事を記載しておきます。

拝聴したセッション

ではここから拝聴したセッションについてざっくり記載します。

懇親会

そう長くない時間で色々あったけどまとめきれないので割愛！ 楽しかった、とだけ言っておく！

色んな人に挨拶できたけど、しきれなかったので来春にリベンジします！

JJUG CCC 2015 Fall、楽しかった！！！

参加してみて私が得たもの

私は講師側として参加しましたが、分かりやすく教えることの難しさを学べました。

また、自分が初心者だった頃に何が分からなかったか、何を分かりたかったか、どうやって分かるようになったか、 などを見つめ直す良いきっかけとなりました。

運営にお誘いくださった @aa7thさん 、 今回のイベント開催のきっかけとなった @ar_keyakiさん 、 それから今回ご参加頂いた皆さん、本当にありがとうございました！

Eclipseへのインポートについて

さて、本日はプロジェクトをEclipseへインポートする箇所で不手際があり参加者の皆さんにはご迷惑をお掛けし、申し訳ありませんでした。

もしご自宅で復習をなさる場合は、改めて https://github.com/javajok/simpletter からZIPファイルをダウンロードし、 gradlew eclipse を行ってインポートしてみてください。

なお、ダウンロードされるファイルの名前は「simpletter-master.zip」です。

APIについて

ハンズオンで使用したAPIのソースコードは次のURLにあります。

• https://github.com/javajok/simpletter-api

こちらもsimpletterと同じく、ZIPファイルをダウンロード・解凍して gradlew eclipse を行うことでEclipseにインポートする形式にできます。

余力がある方・興味がある方は宜しければこのAPIのソースコードも読んで、 色々といじってみてください。

最後に

私は基本的には詰まった時などのサポートに徹していました。

サポートの際はなるべく分かりやすく言葉を選び、そして「こうすれば出来る」だけでなく「なぜそうなるのか」も説明するよう心がけていました。 ですので、もし私のサポートがみなさんの理解の助けになれたのであれば、すごく嬉しいです。

それから、もしまた別のイベントでお会いする事があれば気軽にお声がけください。 今日の事を思い出しながらJavaでWebについてお話しましょう！

それでは繰り返しになりますが、本日は本当にありがとうございました！ すごく楽しかったです！

どうやってんのか

ターミナルの背景色を変更してスペースを2つ出力、を繰り返して絵を描いています。 スペースを2つ出力することで正方形になって良い感じにドット絵っぽくなります。

背景色を変えるには

ESC + '[48;05;' + 色のインデックス + 'm'

で出来ます。

次のGroovyコマンドを試してみてください。

groovy -e "System.out.write(0x1b);println('[48;05;20mHello, World!')"

背景色を元に戻すには

ESC + '[0m'

です。

それから、元画像はターミナルで出力できる色だけで構成されているわけではないので、 元画像から1ピクセルずつ色を読み込んでターミナルで出力できる256色の中から近い色を探して出力しています。

2つの色がどの程度近いかはカラーコードを三次元の座標に見立てて2つの色間の距離を求めて一番近いものを選んでいます。

int r = ((rgb1 >> 16) & 0xff) - ((rgb2 >> 16) & 0xff);
int g = ((rgb1 >> 8) & 0xff) - ((rgb2 >> 8) & 0xff);
int b = (rgb1 & 0xff) - (rgb2 & 0xff);
return (int) Math.sqrt(r * r + g * g + b * b);

概ねこんな感じです。

いろいろブート

うらがみブート。

いろふブート。

ちむブートﾍﾟﾛﾍﾟﾛ（＾ω＾）

こざブート✌️( ・ㅂ・)و🍺

ブートくしーさん。

やんくブート:q!

ソースコード

• https://github.com/backpaper0/spring-boot-rich-banner-sample

関係ありそうな、そうでもないような参考リソース

• http://mike-neck.hatenadiary.com/entry/2015/08/21/034542
• https://docs.oracle.com/javase/jp/8/docs/api/java/lang/invoke/SerializedLambda.html
• https://docs.oracle.com/javase/jp/8/docs/api/java/io/Serializable.html

まとめもオチもない

とりあえず Sample クラスは Serializable をimplementsしましょう。

きっかけ

JAX-RSでWebフォントなどの静的リソースを返すリソースメソッドを書いたんですが、 ETagを使ってキャッシュをアレして転送量を節約したくなりました。

で、ETagにはMD5ハッシュ値を使ってたんですが毎回ハッシュ値を計算するのはあほくさいので、 ビルド時に計算してファイルに保存しておく事にしました。

その際にGradleプラグインを書いて、 どうせならと思って https://plugins.gradle.org/ で公開する事にしました。

Gradleプラグインを書く

次の公式ドキュメント(の日本語訳)を参考にすればオッケー！

• 第58章 カスタムタスクの作成
• 第59章 カスタムプラグインの作成

Gradleプラグインを公開する

How do I add my plugin to the plugin portal? の通りに進めていけばオッケー！

ざっくり書くと、 まず アカウントを作って 、 自分のページでAPI Keyを作って、 それを ~/.gradle/gradle.properties に書いて、 build.gradle へ Plugin Publishing Plugin の設定を書いて、 gradle publishPlugins で公開します。

Gradleプラグインを書くときに知ってて良かったこと

知ってて良かったことっていうかGroovyの文法なんですけど、 次のようなことを知ってたらわりとスムーズにプラグインを書けました。

• アクセサメソッドはフィールドアクセスのように書ける。
  • 例えば foo.getBar() は foo.bar と書ける。
  • そして foo.setBar(baz) は foo.bar = baz と書ける。
• メソッド呼び出しで最後の引数がクロージャだと括弧の外に出せる。 つまり foo(bar, { x -> ... }) は foo(bar) { x -> ... } と書けて組み込みの構文のようにできる。
• 引数がMapなら foo(bar: "...", baz: 123) みたいに書ける。
• 展開演算子。 ['hoge', 'foo', 'x'].collect { it.length() } を ['hoge', 'foo', 'x']*.length() と書ける。
• leftShift という名前のメソッドは << と書ける。 タスクを定義するときの task hoge << { ... } は Task.leftShiftメソッド です。

Gradleプラグインを書くにあたって参考にしたもの

最初に挙げた公式ドキュメントの日本語訳はもちろん参考にしましたが、 他に GradleのAPIドキュメント が参考になりました。

特に次のクラスのドキュメントをよく読んだ気がします。

• Project
• TaskContainer
• Task

それから Gradleのソースコード も参考になりました。 特に JavaPlugin や WarPlugin を参考にしました。

まとめ

Gradleプラグインは書くのも公開するのもお手軽っぽいので、 これを読んで良いなと思ったらチャレンジしてみてくれさい！

ちなみに、こちらが私が書いたプラグインですどうぞ！

• gradle hash plugin

講師・参加者の皆様の感想

• 「Java 8徹底再入門」に登壇しました。 - Programming Studio
• 関ジャバに参加してきました： 【Date and Time API】Java 8徹底再入門【ラムダ式ハンズオン】(大阪,7/11) - ttshikoの日記
• 【Date and Time API】Java 8徹底再入門【ラムダ式ハンズオン】(大阪,7/11)に参加してきました - tomoTakaの日記
• 遠征してました→【Date and Time API】Java 8徹底再入門【ラムダ式ハンズオン】: 迷走記録

build.gradle

まずGrgitを使う準備。 Gradleは普通にGroovyコードを書けて便利。

import org.ajoberstar.grgit.Grgit

ext.repo = Grgit.open(project.file('.'))

buildscript {
    repositories {
        jcenter()
        mavenCentral()
    }
    dependencies {
        classpath('org.ajoberstar:gradle-git:1.1.0')
    }
}

次にハッシュをファイルに書き出すタスクの定義とwarタスクとの依存関係の設定。 今回はwarファイル内の WEB-INF/classes/head にファイルがパッケージングされるようにしました。

task writeHeadCommitHash << {
    def file = new File(buildDir, 'git/head')
    file.parentFile.mkdirs()
    file.write(repo.head().id)
}

war.classpath new File(buildDir, 'git')

war.dependsOn writeHeadCommitHash

JAX-RSのリソースクラス

package javayou;

import java.io.IOException;
import java.net.URISyntaxException;
import java.net.URL;
import java.nio.file.Files;
import java.nio.file.Paths;

import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Named
@RequestScoped
@Path("head")
public class GitCommitHashResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String getHead() {
        URL resource = getClass().getResource("/head");
        if (resource != null) {
            try {
                byte[] b = Files.readAllBytes(Paths.get(resource.toURI()));
                return new String(b);
            } catch (URISyntaxException | IOException ignored) {
            }
        }
        return "<none>";
    }
}

コーディング中にIDEから動かしたとかそういうときはファイルが無いから <none> って表示されるようにしています。

これで、このリソースにアクセスすればどのコミットから作られたwarなのかが分かるます。

動くコード例

• https://github.com/backpaper0/java-you

動かして http://localhost:8080/java-you/api/head を開いてください。

問題

Payara Micro Clustering を見ながらクラスタリング試そうと思ってあれしてみたんですが全然クラスタ組んでくれない！

Payara Microを2つ立ち上げた際の2つめのPayara Microのログの抜粋(クラスタ関連)がこれ。

[2015-06-19T04:03:01.749+0900] [Payara 4.1] [INFO] [] [com.hazelcast.cluster.impl.MulticastJoiner] [tid: _ThreadID=1 _ThreadName=main] [timeMillis: 1434654181749] [levelValue: 800] [[
  [192.168.99.1]:5901 [dev] [3.4.2]


Members [1] {
        Member [192.168.99.1]:5901 this
}
]]

ご覧の通りメンバーがいない！ ソロ活動だ！

クラスタ組んでくだされ〜(´;ω;`)

解決

などとTwitterで嘆いてたら かずひらさん が助けてくれた！

NICも指定できないし… あとは、-Djava.net.preferIPv4Stack=trueにしてIPv4にしてみるとかかな…

— かずひら (@kazuhira_r) 2015, 6月 18

かずひらさん、それです！

というわけで次のようにすればいけた。

java -Djava.net.preferIPv4Stack=true -jar payara-micro-4.1.152.1.jar --deploy clusterjsp.war --port 8000

これでクラスタが組める！ 組めるぞおおおおおおお！ ( ﾟ∀ﾟ)ｱﾊﾊ八八ﾉヽﾉヽﾉヽﾉ ＼ / ＼/ ＼

[2015-06-19T04:11:18.909+0900] [Payara 4.1] [INFO] [] [com.hazelcast.cluster.ClusterService] [tid: _ThreadID=45 _ThreadName=hz.glassfish-web.server.generic-operation.thread-1] [timeMillis: 1434654678909] [levelValue: 800] [[
  [192.168.99.1]:5900 [dev] [3.4.2]

Members [21] {
        Member [192.168.99.1]:5900 this
        Member [192.168.99.1]:5901
        Member [192.168.99.1]:5902
        Member [192.168.99.1]:5903
        Member [192.168.99.1]:5904
        Member [192.168.99.1]:5905
        Member [192.168.99.1]:5906
        Member [192.168.99.1]:5907
        Member [192.168.99.1]:5908
        Member [192.168.99.1]:5909
        Member [192.168.99.1]:5910
        Member [192.168.99.1]:5911
        Member [192.168.99.1]:5912
        Member [192.168.99.1]:5913
        Member [192.168.99.1]:5914
        Member [192.168.99.1]:5915
        Member [192.168.99.1]:5916
        Member [192.168.99.1]:5917
        Member [192.168.99.1]:5918
        Member [192.168.99.1]:5919
        Member [192.168.99.1]:5920
}
]]

無駄に21クラスタ！

ここまで書いて、 まだまだいけんじゃね？と思い、 調子に乗ってPMC48(Payara Micro Clusterデス)とかやろうとしたけど30パヤラ越えたあたりからMacさんが唸りだしたのでビビって止めてしまった。

謝辞

かずひらさんありがとうございました！！！

やりたいこと

リソースメソッドをトランザクション境界にしたい。

話題に出た方法

ContainerRequestFilter や ContainerResponseFilter を使って実現できないかなー、という話が出ましたが私は無理だと思っています。

ContainerRequestFilter はリソースメソッドの前に実行されるだけ、 ContainerResponseFilter はリソースメソッドの後に実行されるだけで try-catch-finally ができないからです。

パッと思いつく方法

GlasFishなどJava EE 7準拠のアプリケーションサーバで動かすのであればリソースクラスを CDI管理ビーンにして @Transactional で注釈すればそれだけでリソースメソッドがトランザクション境界になります。

Tomcat + Jerseyぐらいの構成で実現する方法

CDI使ってない、っていうかTomcatで動かしてる、つーかDIコンテナ使ってない！！！という場合はどうすれば良いのか？

Jerseyは内部的に HK2 というDIコンテナを使っています。 このHK2のAOP機能を利用してリソースクラスにインテーセプターを適用して リソースメソッドをトランザクション境界にする方法が取れます。

ザクッとサンプル書いてみたので詳細はコードを読んでください。

• https://github.com/backpaper0/jersey-interceptor-sample

まとめ

• JAX-RSの仕様ではサーブレットフィルタのような try-catch-finally ができるポイントが無い
• CDIを併用すれば何とでもなる
• Jerseyなら実装に依存するけどHK2を使うことで何とかなる

ちなみに

東京でも開催されるっぽいですよ！

あ、Spring Bootキャンプ、3/25に東京でもやります。イベントページまだか・・・

— Toshiaki Maki (@making) 2015, 3月 7

おまけ

Spring Boot + Jersey。 懇親会で話題に出たやつです。 前にちょこっとやりました。

• Spring BootのサンプルをJAX-RSにしてみた

ファイルの読み書き

Path path = Paths.get("path/to/file");
try (BufferedReader in = Files.newBufferedReader(path)) {
    //読み込み処理
}

try (BufferedReader in = Files.newBufferedReader(path, Charset.forName("Windows-31J"))) {
    String line;
    while(null != (line = in.readLine())) {
        //読み込み処理
    }
}

try (InputStream in = new BufferedInputStream(Files.newInputStream(path))) {
    byte[] b = new byte[1000];
    int i;
    while (-1 != (i = in.read(b))) {
        //読み込み処理
    }
}

try (BufferedWriter out = Files.newBufferedWriter(path)) {
    //書き出し処理
}

try (OutputStream out = new BufferedOutputStream(Files.newOutputStream(path))) {
    //書き出し処理
}

オンメモリで扱う

Writer を渡したらそこにもろもろ書き出してくれるライブラリがあるんだけど わざわざファイルに書き出すんじゃなくてオンメモリで処理して String で結果を取りたいんや！ というような場合には StringWriter を使います。

StringWriter out = new StringWriter();
library.writeTo(out);
String result = out.toString();

Reader / InputStream / OutputStream にもそれぞれオンメモリで使用するためのクラスがあります。

• StringReader は String を読み込める Reader
• StringWriter は String へ書き出せる Writer
• ByteArrayInputStream は byte[] を読み込める InputStream
• ByteArrayOutputStream は byte[] へ書き出せる OutputStream

InputStreamをReaderへ/OutputStreamをWriterへ変換する

それぞれ InputStreamReader と OutputStreamWriter を使って変換できます。

InputStream in = ...
Reader reader = new InputStreamReader(in, StandardCharsets.UTF_8);

OutputStream out = ...
Writer writer = new OutputStreamWriter(out, StandardCharsets.UTF_8);

第二引数に Charset を渡していますが、何も渡さない場合はデフォルトエンコーディングが使用されるので注意が必要です。 デフォルトエンコーディングとはシステムプロパティ file.encoding で取得できるものです。 変更したい場合は次のようにJava起動時にオプションを設定します。

java -Dfile.encoding=UTF-8 com.example.MainClass

ZIPファイルを読み込む/書き出す

ZIPファイルの読み書きには ZipInputStream と ZipOutputStream が使えます。

InputStream in = ...
try(ZipInputStream zin = new ZipInputStream(in, StandardCharsets.UTF_8)) {
    ZipEntry zipEntry;
    while (null != (zipEntry = zin.getNextEntry())) {
        byte[] b = new byte[1000];
        int i;
        while (-1 != (i = zin.read(b))) {
            //読み込み処理
        }
    }
}

OutputStream out = ...
try(ZipOutputStream zout = new ZipOutputStream(out, StandardCharsets.UTF_8)) {
    ZipEntry zipEntry = new ZipEntry("hoge.txt");
    zout.putNextEntry(zipEntry);
    byte[] b = ...
    zout.write(b);
    zout.closeEntry();
}

ファイルのコピー、移動をする

Files を使います。

Path src = ...
Path dest = ...

Files.copy(src, dest);

Files.move(src, dest);

Channel

Reader / Writer / InputStream / OutputStream の他に Channel というものもありますが Channel が必要になるライブラリには ほぼ出会った事がないので覚えなくても生きて行けると思います。

おまけ

テキストファイルの読み込みには Files.newBufferedReader を使うと書きましたが Java 6までは FileReader を使って次のようにファイル読み込みをしていました。

File file = new File("path/to/file");
Reader in = new FileReader(file);
try {
    //読み込み処理
} finally {
    in.close();
}

Charset を渡さずに FileReader をインスタンス化していますが、 この場合はデフォルトエンコーディングが使われていました。

しかも FileReader には Charset を受け取るコンストラクタは用意されていません。 ではデフォルトエンコーディング以外でファイルを読み込みたい場合はどうするのか？

その場合は、

1. FileInputStream でファイルを開いて
2. InputStreamReader で Charset を指定しつつラップする

という方法をとっていました。

File file = new File("path/to/file");
Reader in = new InputStreamReader(new FileInputStream(file), Charset.forName("iso-2022-jp"));
try {
    //読み込み処理
} finally {
    in.close();
}

そういう訳で java.io で Charset を受け取らない場合はデフォルトエンコーディング、 java.nio.file で Charset を受け取らない場合はUTF-8が使われる、という感じです。

デフォルトエンコーディングは環境によって変わるので java.nio.file を使っておくのが安全だと思います。

DisableOnDebug

DisableOnDebug 他の TestRule をラップして、 デバッグ実行されているときのみラップした TestRule を適用します。

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.DisableOnDebug;
import org.junit.rules.TestRule;
import org.junit.rules.Timeout;

public class HogeTest {

    @Rule
    public TestRule timeout = new DisableOnDebug(Timeout.seconds(1)); //1秒以上かかったら失敗とみなす

    @Test
    public void testHoge() throws Exception {
        //test code
    }
}

こんな感じで Timeout と組み合わせる事が多い気がします。

コマンドライン引数に次のいずれかが含まれていればデバッグ実行されていると判断するようです。

• -Xdebug
• -agentlib:jdwp

デバッグ実行かどうかの判断は DisableOnDebug.isDebugging メソッドをオーバーライドすればカスタマイズできます。

Stopwatch

Stopwatch はテスト実行にかかった時間を System.nanoTime メソッドで計測します。

import java.util.logging.Logger;

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.Stopwatch;
import org.junit.runner.Description;

public class FugaTest {

    private static Logger logger = Logger.getLogger(FugaTest.class.getName());

    @Rule
    public Stopwatch stopwatch = new Stopwatch() {
        @Override
        protected void succeeded(long nanos, Description description) {
            logger.info(() -> String.format("テストの実行に%,dナノ秒かかった", nanos));
        }
    };

    @Test
    public void test() throws Exception {
        //test code
    }
}

ロギング目的に使うのが多そうです。

マージする

git checkout master
git merge other -m "Merge branch 'other'"
git branch -d other

操作が分かりやすい感じがする。

リベースする

git checkout master
git rebase master other
git checkout master
git merge other
git branch -d other

コミットが一本化する。

リベースしてからマージする

git checkout master
git rebase master other
git checkout master
git merge other --no-ff -m "Merge branch 'other'"
git branch -d other

コミットが一本化しつつブランチ単位の作業を把握しやすい。

まとめ

私はリベースしてからマージする派！

#!/bin/sh
rm -fr .git *.txt .gitignore
git init
echo init.sh>.gitignore && git add .gitignore && git commit -m "Initial Commit"
echo b>b.txt && git add b.txt && git commit -m "master 1"
git branch other
echo c>c.txt && git add c.txt && git commit -m "master 2"
echo d>d.txt && git add d.txt && git commit -m "master 3"
git checkout other
echo e>e.txt && git add e.txt && git commit -m "other 1"
echo f>f.txt && git add f.txt && git commit -m "other 2"
git checkout master

セットアップツールによるプロジェクトの生成

ダウンロードページ で “Download Setup App” をクリックして gdx-seup.jar をダウンロードしてください。

ダウンロードできたらダブルクリック、もしくは次のコマンドで実行してください。

java -jar gdx-setup.jar

各項目を編集します。

“LibGDX Version” は最新のものが選択されているはずなので、そのままで。

“Sub Projects” はすべてチェックされていると思います。 不要になればその時点で取り除けば良いし個別にビルドもできるので、これもそのままで。

“Extensions” は “Box2d” のみがチェックされていると思います。 ここについては詳しい解説が出来るほどの知識がありません。 誰か教えてください！ これもそのままでいきましょう。

以上の状態で “Generate” を押してください。

初回はGradleや依存JARのダウンロードが行われるので時間がかかります。 お茶でも飲んでお待ちください。

次のようなログが出ると完了です。

BUILD SUCCESSFUL

Total time: 42.551 secs
Done!
To import in Eclipse: File -> Import -> Gradle -> Gradle Project
To import to Intellij IDEA: File -> Import -> build.gradle
To import to NetBeans: File -> Open Project...

寄り道：Gitでバージョン管理を始める

今後の事を考えてGitでのバージョン管理を始めておきましょう。

セットアップツールが .gitignore も出力してくれているのでややこしいことは何も考えずにバージョン管理を始められます。

git init
git add .
git commit -m "Initial commit"

Eclipseへのインポート

セットアップのログを見た感じだとEclipseにGradleプラグインが入っているとそのままインポート出来そうですね。

私はGradleプラグインが入っていないEclipseを使っているので、その場合のインポート方法を書きます。

まずGradleでコマンドを実行します。

gradlew eclipse

次にEclipseのメニューから File ‣ Import ‣ General ‣ Existing Projects into Workspace を選択します。 それから “Select root directory” にプロジェクトのパスを入力してください。

pwd|pbcopy

cd|clip

インポートするプロジェクトは code と desktop だけで良いでしょう。 基本的にはデスクトップで開発してたまに実機確認という感じで進められると思います。

インポートできたら（これが面倒なのですが）desktopプロジェクトにあるassetsディレクトリをクラスパスに加えてください。

手っ取り早い方法はassetsディレクトリで右クリックして Build Path ‣ Use as Source Folder です。

もしくは、プロジェクトのプロパティを開いて Java Build Path ‣ Libraries と辿って “Add Class Folder” を押してassetsディレクトリを指定してください。

IntelliJ IDEAへのインポート

私はIntelliJ IDEA分からんのですが、セットアップのログに書かれているように File ‣ Import ‣ build.gradle をやってみたところインポートできたっぽいです。

実行する

desktopプロジェクトの src/main/java/yourpackage/DesktopLauncher.java を実行してください。 ( yourpackage はセットアップ時に設定したパッケージです。 適宜読み替えてください。)

結び

というわけでlibGDXプロジェクトのセットアップ方法を記載してみました。

libGDXはAndroidアプリであってもデスクトップ中心で開発でき、 コードの殆どを共有できるのがすごくて嬉しくてお気に入りです。

願わくばもっともっとlibGDXユーザーが増えますように！

本題

特に書くことない。 普通に置き換えたら普通に動いたので。

ただしスコープのアノテーションはSpringのままです。 セッションスコープのクラスに付けたアノテーションを @SessionScoped に変更したかったのですがJSR 330ではなくCDIのアノテーションのためどうしようもなかったというかなんというか。

まあいいか。

まとめ

JSR 330のアノテーションの方が見慣れていて個人的には良い。

試した

ハローワールドな、なんの役にも立たないWeb APIを作って試してみました。

• https://github.com/backpaper0/sandbox/tree/master/jersey2_15-cdi-example

メインクラスはこんな感じ。

package example;

import java.net.URI;

import org.glassfish.jersey.jdkhttp.JdkHttpServerFactory;
import org.glassfish.jersey.server.ResourceConfig;
import org.jboss.weld.environment.se.Weld;

import com.sun.net.httpserver.HttpServer;

public class App {

    public static void main(String[] args) {
        Weld weld = new Weld();
        weld.initialize();
        URI uri = URI.create("http://localhost:8080/");
        ResourceConfig config = new ResourceConfig(HelloResource.class);
        HttpServer server = JdkHttpServerFactory.createHttpServer(uri, config);
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            server.stop(0);
            weld.shutdown();
        }));

        System.out.println("http://localhost:8080/hello?name=YourName");
    }
}

ご覧の通りです。 普通にWeldを動かして、Jerseyを動かしてるだけです。 簡単です。

pom.xmlのdependencyはこんな感じ。

<dependency>
  <groupId>org.glassfish.jersey.ext.cdi</groupId>
  <artifactId>jersey-weld2-se</artifactId>
</dependency>
<dependency>
  <groupId>org.glassfish.jersey.ext.cdi</groupId>
  <artifactId>jersey-cdi1x</artifactId>
</dependency>

所感

私はJava EEは好きですがJava SEでも簡単に動くようになるのは嬉しいのでこの変更は嬉しいです！

アホっぽい感想ですが、まあそんな感じでー。

本題

まず、おもむろにgradle initしました。

gradle init

すでにpom.xmlがあるので依存関係とか色々よろしくやってくれたbuild.gradleが出力されました。

apply plugin: 'java'
apply plugin: 'maven'

group = 'sample'
version = '1.0-SNAPSHOT'

description = """spring-boot-sample"""

sourceCompatibility = 1.8
targetCompatibility = 1.8



repositories {

     maven { url "http://repo.maven.apache.org/maven2" }
}
dependencies {
    compile group: 'org.twitter4j', name: 'twitter4j-core', version:'4.0.2'
    compile(group: 'org.springframework.boot', name: 'spring-boot-starter-jersey', version:'1.2.1.RELEASE') {
exclude(module: 'spring-webmvc')
    }
    compile(group: 'org.glassfish.jersey.ext', name: 'jersey-mvc', version:'2.14') {
exclude(module: 'servlet-api')
    }
    compile group: 'org.springframework.boot', name: 'spring-boot-starter-thymeleaf', version:'1.2.1.RELEASE'
    testCompile(group: 'org.springframework.boot', name: 'spring-boot-starter-test', version:'1.2.1.RELEASE') {
exclude(module: 'commons-logging')
    }
    testCompile group: 'junit', name: 'junit', version:'4.12'
}

あとはSpring Bootのリファレンスの 10.1.2 Gradle installation を参考にしてちょこちょこっと編集しました。

buildscript {
  repositories {
    jcenter()
    maven { url "http://repo.spring.io/snapshot" }
    maven { url "http://repo.spring.io/milestone" }
  }
  dependencies {
    //ここで拡張プロパティspringBootVersionは参照できひんの？_(:3｣∠)_
    classpath("org.springframework.boot:spring-boot-gradle-plugin:1.2.1.RELEASE")
  }
}

apply plugin: 'java'
apply plugin: 'spring-boot'
apply plugin: 'eclipse'
apply plugin: 'idea'

group = 'sample'
version = '1.0-SNAPSHOT'

sourceCompatibility = 1.8
targetCompatibility = 1.8

ext {
  springBootVersion = '1.2.1.RELEASE'
}

repositories {
  jcenter()
  maven { url "http://repo.spring.io/snapshot" }
  maven { url "http://repo.spring.io/milestone" }
}

dependencies {
  compile 'org.twitter4j:twitter4j-core:4.0.2'
  compile ("org.springframework.boot:spring-boot-starter-jersey:$springBootVersion") {
    exclude(module: 'spring-webmvc')
  }
  compile ('org.glassfish.jersey.ext:jersey-mvc:2.14') {
    exclude(module: 'servlet-api')
  }
  compile "org.springframework.boot:spring-boot-starter-thymeleaf:$springBootVersion"
  testCompile ("org.springframework.boot:spring-boot-starter-test:$springBootVersion") {
    exclude(module: 'commons-logging')
  }
  testCompile 'junit:junit:4.12'
}

知りたいこと

build.gradleにも書いたけどbuildscriptのブロック内で拡張プロパティspringBootVersionを参照できないのでしょうか？ （試しに使ってみたらビルド失敗した。。。）

教えてくださいお願いしますお願いします（他力本願）。

まとめ

Gradle化すげえ簡単だった。

あわせて読みたい

• 初心者大歓迎! webアプリを作ってみよう!勉強会のレポ起因にブログ書いてもらったからやってみた！！！ - そこに仁義はあるのか(仮)

やったこと

まず Spring Bootのドキュメント を参考にしてpom.xmlの編集とJerseyConfigクラスを作成しました。

次に Jerseyのリファレンス を参考にしてTemplateProcessorの実装クラスを作成しました。

そして各ControllerクラスをSpring MVC仕様からJAX-RS仕様に変更しました。 詳細書くのは面倒なのでコミット見てください。

例外出た

一通りコードを書いて、IDEから動かしたら起動時に例外が出ました。

java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
    at java.util.concurrent.FutureTask.report(FutureTask.java:122)
    at java.util.concurrent.FutureTask.get(FutureTask.java:192)
    at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:917)
    at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:868)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1409)
    at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1399)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
    ... 6 common frames omitted
Caused by: java.lang.NoSuchMethodError: javax.servlet.ServletContext.addFilter(Ljava/lang/String;Ljavax/servlet/Filter;)Ljavax/servlet/FilterRegistration$Dynamic;
    at org.springframework.boot.context.embedded.FilterRegistrationBean.onStartup(FilterRegistrationBean.java:250)
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.selfInitialize(EmbeddedWebApplicationContext.java:222)
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.access$000(EmbeddedWebApplicationContext.java:84)
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext$1.onStartup(EmbeddedWebApplicationContext.java:206)
    at org.springframework.boot.context.embedded.tomcat.TomcatStarter.onStartup(TomcatStarter.java:54)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5185)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    ... 6 common frames omitted

なんかサーブレットAPIが古いようです。

十中八九Jersey関連が持ってきたんだろうな、と思いつつ、調査しました。 maven-dependency-plugin の treeゴールを使えば依存関係を一覧できます。 -l オプションでログをファイルに書き出してエディタで検索するのが楽だと思います。

mvn -l log.txt dependency:tree -Dscope=test

Mavenを実行すると次のようなログが書き出されました。

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building spring-boot-sample 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ spring-boot-sample ---
[INFO] sample:spring-boot-sample:jar:1.0-SNAPSHOT
[INFO] +- org.twitter4j:twitter4j-core:jar:4.0.2:compile
[INFO] +- org.springframework.boot:spring-boot-starter-jersey:jar:1.2.1.RELEASE:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter:jar:1.2.1.RELEASE:compile
[INFO] |  |  +- org.springframework.boot:spring-boot:jar:1.2.1.RELEASE:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-autoconfigure:jar:1.2.1.RELEASE:compile
[INFO] |  |  +- org.springframework.boot:spring-boot-starter-logging:jar:1.2.1.RELEASE:compile
[INFO] |  |  |  +- org.slf4j:jcl-over-slf4j:jar:1.7.8:compile
[INFO] |  |  |  +- org.slf4j:jul-to-slf4j:jar:1.7.8:compile
[INFO] |  |  |  +- org.slf4j:log4j-over-slf4j:jar:1.7.8:compile
[INFO] |  |  |  \- ch.qos.logback:logback-classic:jar:1.1.2:compile
[INFO] |  |  |     \- ch.qos.logback:logback-core:jar:1.1.2:compile
[INFO] |  |  \- org.yaml:snakeyaml:jar:1.14:runtime
[INFO] |  +- org.springframework.boot:spring-boot-starter-tomcat:jar:1.2.1.RELEASE:compile
[INFO] |  |  +- org.apache.tomcat.embed:tomcat-embed-core:jar:8.0.15:compile
[INFO] |  |  +- org.apache.tomcat.embed:tomcat-embed-el:jar:8.0.15:compile
[INFO] |  |  +- org.apache.tomcat.embed:tomcat-embed-logging-juli:jar:8.0.15:compile
[INFO] |  |  \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.0.15:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.4.4:compile
[INFO] |  |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.4.4:compile
[INFO] |  |  \- com.fasterxml.jackson.core:jackson-core:jar:2.4.4:compile
[INFO] |  +- org.hibernate:hibernate-validator:jar:5.1.3.Final:compile
[INFO] |  |  +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] |  |  +- org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
[INFO] |  |  \- com.fasterxml:classmate:jar:1.0.0:compile
[INFO] |  +- org.springframework:spring-core:jar:4.1.4.RELEASE:compile
[INFO] |  +- org.springframework:spring-web:jar:4.1.4.RELEASE:compile
[INFO] |  |  +- org.springframework:spring-aop:jar:4.1.4.RELEASE:compile
[INFO] |  |  |  \- aopalliance:aopalliance:jar:1.0:compile
[INFO] |  |  +- org.springframework:spring-beans:jar:4.1.4.RELEASE:compile
[INFO] |  |  \- org.springframework:spring-context:jar:4.1.4.RELEASE:compile
[INFO] |  |     \- org.springframework:spring-expression:jar:4.1.4.RELEASE:compile
[INFO] |  +- org.glassfish.jersey.core:jersey-server:jar:2.14:compile
[INFO] |  |  +- org.glassfish.jersey.core:jersey-common:jar:2.14:compile
[INFO] |  |  |  +- org.glassfish.jersey.bundles.repackaged:jersey-guava:jar:2.14:compile
[INFO] |  |  |  \- org.glassfish.hk2:osgi-resource-locator:jar:1.0.1:compile
[INFO] |  |  +- org.glassfish.jersey.core:jersey-client:jar:2.14:compile
[INFO] |  |  +- javax.annotation:javax.annotation-api:jar:1.2:compile
[INFO] |  |  +- org.glassfish.hk2:hk2-api:jar:2.4.0-b06:compile
[INFO] |  |  |  +- org.glassfish.hk2:hk2-utils:jar:2.4.0-b06:compile
[INFO] |  |  |  \- org.glassfish.hk2.external:aopalliance-repackaged:jar:2.4.0-b06:compile
[INFO] |  |  +- org.glassfish.hk2.external:javax.inject:jar:2.4.0-b06:compile
[INFO] |  |  \- org.glassfish.hk2:hk2-locator:jar:2.4.0-b06:compile
[INFO] |  |     \- org.javassist:javassist:jar:3.18.1-GA:compile
[INFO] |  +- org.glassfish.jersey.containers:jersey-container-servlet-core:jar:2.14:compile
[INFO] |  +- org.glassfish.jersey.containers:jersey-container-servlet:jar:2.14:compile
[INFO] |  +- org.glassfish.jersey.ext:jersey-spring3:jar:2.14:compile
[INFO] |  |  +- org.glassfish.hk2:hk2:jar:2.4.0-b06:compile
[INFO] |  |  |  +- org.glassfish.hk2:config-types:jar:2.4.0-b06:compile
[INFO] |  |  |  +- org.glassfish.hk2:core:jar:2.4.0-b06:compile
[INFO] |  |  |  +- org.glassfish.hk2:hk2-config:jar:2.4.0-b06:compile
[INFO] |  |  |  |  +- org.jvnet:tiger-types:jar:1.4:compile
[INFO] |  |  |  |  \- org.glassfish.hk2.external:bean-validator:jar:2.4.0-b06:compile
[INFO] |  |  |  +- org.glassfish.hk2:hk2-runlevel:jar:2.4.0-b06:compile
[INFO] |  |  |  \- org.glassfish.hk2:class-model:jar:2.4.0-b06:compile
[INFO] |  |  |     \- org.glassfish.hk2.external:asm-all-repackaged:jar:2.4.0-b06:compile
[INFO] |  |  \- org.glassfish.hk2:spring-bridge:jar:2.4.0-b06:compile
[INFO] |  \- org.glassfish.jersey.media:jersey-media-json-jackson:jar:2.14:compile
[INFO] |     +- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.3.2:compile
[INFO] |     \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.3.2:compile
[INFO] |        \- com.fasterxml.jackson.module:jackson-module-jaxb-annotations:jar:2.3.2:compile
[INFO] +- org.glassfish.jersey.ext:jersey-mvc:jar:2.14:compile
[INFO] |  +- javax.servlet:servlet-api:jar:2.4:compile
[INFO] |  \- javax.ws.rs:javax.ws.rs-api:jar:2.0.1:compile
[INFO] +- org.springframework.boot:spring-boot-starter-test:jar:1.2.1.RELEASE:test
[INFO] |  +- org.mockito:mockito-core:jar:1.10.8:test
[INFO] |  |  \- org.objenesis:objenesis:jar:2.1:test
[INFO] |  +- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] |  +- org.hamcrest:hamcrest-library:jar:1.3:test
[INFO] |  \- org.springframework:spring-test:jar:4.1.4.RELEASE:test
[INFO] +- org.springframework.boot:spring-boot-starter-thymeleaf:jar:1.2.1.RELEASE:compile
[INFO] |  +- org.springframework.boot:spring-boot-starter-web:jar:1.2.1.RELEASE:compile
[INFO] |  |  \- org.springframework:spring-webmvc:jar:4.1.4.RELEASE:compile
[INFO] |  +- org.thymeleaf:thymeleaf-spring4:jar:2.1.4.RELEASE:compile
[INFO] |  |  +- org.thymeleaf:thymeleaf:jar:2.1.4.RELEASE:compile
[INFO] |  |  |  +- ognl:ognl:jar:3.0.8:compile
[INFO] |  |  |  \- org.unbescape:unbescape:jar:1.1.0.RELEASE:compile
[INFO] |  |  \- org.slf4j:slf4j-api:jar:1.7.8:compile
[INFO] |  \- nz.net.ultraq.thymeleaf:thymeleaf-layout-dialect:jar:1.2.7:compile
[INFO] \- junit:junit:jar:4.12:test
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.425 s
[INFO] Finished at: 2015-01-14T23:02:38+09:00
[INFO] Final Memory: 21M/165M
[INFO] ------------------------------------------------------------------------

servlet-apiを検索してヒットした箇所を見るとやはりjersey-mvcが依存していました。

dependency要素にexclusion要素を追加してservlet-apiへの依存を除外した ところIDEからも起動できました。

所感

Spring MVCはMVCと言うだけあってビューを持つアプリケーションはさくさく作れそうな気がしました。

それに対してJAX-RSは単純にJSONを返すというようなAPIを作るのに特化してるなー、と改めて思いました。

まあ、そんな感じで。 おしまい。

HttpServletRequestとHttpSessionをなくす

さて、出来上がったアプリケーションでは HttpServletRequest と HttpSession を使っている箇所があったのでそれらを使わないように変更します。

まずは HttpServletRequest を消します。 Twitterの認証から戻ってくるときに oauth_verifier というリクエストパラメータを受け取っている所に使われています。 これをTwitterControllerのdoTweetメソッドと同じやり方で受け取るように変更します。

@RequestMapping("accessToken")
public String accessToken(Model model,
        @RequestParam(value = "oauth_verifier", required = true) String verifier)
        throws TwitterException {

次いでHttpSessionを消します。 認証の際に必要となるリクエストトークンとアクセストークンを保持するために HttpSession が使用されているようです。 今回はそれらを格納するセッションスコープのクラスを作ってコントローラーにインジェクションする方法をとります。

まずこれがトークンを格納するセッションスコープのクラス。

package jp.co.bizreach.spring_boot_sample;

import java.io.Serializable;

import org.springframework.context.annotation.Scope;
import org.springframework.context.annotation.ScopedProxyMode;
import org.springframework.stereotype.Component;
import org.springframework.web.context.WebApplicationContext;

import twitter4j.auth.AccessToken;
import twitter4j.auth.RequestToken;

@Component
@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS,
        value = WebApplicationContext.SCOPE_SESSION)
public class TwitterAuth implements Serializable {

    private AccessToken accessToken;

    private RequestToken requestToken;

    public AccessToken getAccessToken() {
        return accessToken;
    }

    public void setAccessToken(AccessToken accessToken) {
        this.accessToken = accessToken;
    }

    public RequestToken getRequestToken() {
        return requestToken;
    }

    public void setRequestToken(RequestToken requestToken) {
        this.requestToken = requestToken;
    }
}

TwitterAuthController と TwitterController には次のようにフィールドにインジェクションします。

@Autowired
private TwitterAuth auth;

あとはこのフィールドを使ってトークンを格納したり取り出したりすればオッケーです。

これでサーブレットAPIをなくすことが出来ました！

pom.xmlを作る

しょぼちむのブログより

今回はサンプルアプリを作ってくれていて、基本的にはそれを動かしてみるって感じだったけど、pomファイルの作成のところからやってみたかったかも。

作成しましょう！

サンプルはmvn archetype:generateで空のプロジェクトを作ったあとに pom.xmlを編集してdependencyを追加したように見えます。

適当なディレクトリでmvn archetype:generateを実行します。

mvn archetype:generate

すると色んな雛形が一覧でずらーっと出てくるので使いたいものを番号で指定します。

今回はデフォルトの maven-archetype-quickstart を使用しますので数字は何も入力せず次に進みます。

maven-archetype-quickstart のバージョンを尋ねられます。 既に最新が選択されているのでここも何も入力せず次に進みます。

ここから groupId、artifactId、version、そしてアプリケーションの package を尋ねられます。 適宜入力してそのまま進むと次のようなログが出て空のプロジェクトが作成されます。

[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Old (1.x) Archetype: maven-archetype-quickstart:1.1
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: basedir, Value: /Users/backpaper0/src/temp
[INFO] Parameter: package, Value: app
[INFO] Parameter: groupId, Value: sample
[INFO] Parameter: artifactId, Value: spring-boot-sample
[INFO] Parameter: packageName, Value: app
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] ********************* End of debug info from resources from generated POM ***********************
[INFO] project created from Old (1.x) Archetype in dir: /Users/backpaper0/src/temp/spring-boot-sample
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 55.560 s
[INFO] Finished at: 2015-01-12T12:38:58+09:00
[INFO] Final Memory: 14M/95M
[INFO] ------------------------------------------------------------------------

作成されたファイルは次のような感じ。

• ./pom.xml
• ./src/main/java/app/App.java
• ./src/test/java/app/AppTest.java

pom.xmlとHello, world!するだけのクラス(App.java)とassertTrue(true)するだけのテストクラス(AppTest.java)です。

App.java と AppTest.java は要らないので消します。

それからpom.xmlを編集します。

mvn archetype:generateした直後の状態は次のような感じです。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>sample</groupId>
  <artifactId>spring-boot-sample</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>spring-boot-sample</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

これに リファレンスの10.1.1 Maven installation を参考にして parent要素と dependency要素を追加しました。 あとついでにJUnitのバージョンを4.12に上げました。 それとmaven-compiler-pluginの設定を追加してJava 8でビルドされるようにしました。 んでもって、spring-boot-maven-pluginの設定を追加してスタンドアロンJARを作れるようにしました。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>sample</groupId>
  <artifactId>spring-boot-sample</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>spring-boot-sample</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.2.1.RELEASE</version>
  </parent>

  <dependencies>
    <dependency>
      <groupId>org.twitter4j</groupId>
      <artifactId>twitter4j-core</artifactId>
      <version>4.0.2</version>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-test</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-thymeleaf</artifactId>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
          <encoding>${project.build.sourceEncoding}</encoding>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

これで概ねハンズオンのpom.xmlに近くなったと思います。

今後の予定

リファレンスには 10.1.2 Gradle installation というのがあったのでGradle化してみたいですね。

それと spring-boot-starter-jersey というのがあるっぽいのでSpring MVCをJAX-RSに置き換えるというのもやってみたいです。

……やらない雰囲気が漂っていますが気にしない方向で！

まとめ

ひとのブログを写経しただけっていう他力本願がひどいブログ初めでした。

今年もよろしくお願い致します。

今日のコード

• https://github.com/backpaper0/spring_boot_sample

あわせて読みたい

• 初心者大歓迎! webアプリを作ってみよう!勉強会のレポ起因にブログ書いてもらったからやってみた！！！ - そこに仁義はあるのか(仮)

「しょぼつむ」作りました

さて、今回私はしょぼちむをモチーフにして「しょぼつむ」というゲーム作ってみました。 ゲームのイメージを貼ります。

ルールは至ってシンプルです。 画面の下の方に見えているハート・レッドキング・雪だるまを指で弾くと飛んで行って着地します。 制限時間10秒の間に次々と弾いて高く積み上げてください。 雪降るクリスマスの街に積み上がった分だけ女子力が手に入ります。 という、なんかもうこの時点でしょぼちむすまん、と言いたくなる感じのコンセプトです。

積むものによってポイントが異なります。

• ハート：5ポイント
• レッドキング：2ポイント
• 雪だるま：1ポイント

ハートはポイント稼げますが落下速度がのんびりしています。

野良apkファイルを用意しました。 良ければ遊んでみてください。

• /assets/android-release.apk

ソースコードはこちら。

• https://github.com/backpaper0/syobotsum

gradlew android:build したらapkをビルドできます。

ちなみに実機で確認していません(ｷﾘｯ

ゲームを作ってみて

すごく簡単なゲームですがゲーム作り初心者には難しい部分もありました。

しかし技術的な難しさよりもゲームシステムのアイデアが出なかったり絵の準備に手間取ってしまいました。

アドベントカレンダーのネタを考えていたときに「しょぼつむ」という言葉が先に浮かんだので何かを積むものにしようとは思っていたのですが、 ぷよぷよのような落ちものゲームにしようかなー、 それとも将棋崩しのようなものも積むという基本コンセプトからは逸脱しないかなー、 など悩みました。

悩みはしましたがなんせ普段はWebアプリでCRUDの亜種みたいなのばっか作ってる身としては凝った事をやるとしぬと思い、 シンプルなルールになるよう考えた末に前記のようなものになりました。

コーディングも普段やってる事とは異なりましたがなるべく高レベルAPIを利用する事で なんとか形に出来ました。

TODO

とりあえず動きますが未完成です。 次にTODOを記載します。

• SEとBGMを付けたい
• ヘルプを組込みたい。ブログに操作方法書くとかアレ
• フェードアウト時、各パーツの枠のちらつきをなんとかしたい
• 画像のロードを非同期にしたい
• 結果画面がおとなしいからもっとわちゃわちゃさせたい
• ソースコードにコメントほぼないの、たぶん後で困るから覚えてるうちに書いておきたい

特にBGMはせっかくなので作曲したいと考えていましたがそんな時間はなかった（まがお

そもそもパソコンで曲作るのってどうしたら良いですかね？ 教えてえろいひと！（他力本願

技術的な話

「しょぼつむ」はlibGDXで開発をしました。

• http://libgdx.badlogicgames.com/

libGDXはJavaで書かれたゲームフレームワークで、ささーっとコードを書くとそのコードをデスクトップアプリ、Androidアプリ、iOSアプリなどにビルド出来るスゴいやつです。

私はAndroidスマホ持っていないしiOS開発者ライセンスも持っていないのでプライベートでスマホアプリ開発はしないのですが、 libGDXであればJava SEで書いてデスクトップで動かせるので私のような者であってもスマホアプリ開発が出来てしまいました。

libGDXの事を詳しく知りたい方は GitHubにあるlibGDXのWiki を読むか「libGDX しんさん」でググると良いでしょう。

まとめ

• ゲーム作るの難しい
• libGDXすごく良い

明日のアドベントカレンダーは

しょぼちむの番でフィナーレ ですね！

リクエストパラメータをOptionalで受け取るコード例

適当ですがサクッちょとサンプル書きました。

• https://github.com/backpaper0/sandbox の jersey-optional-example ディレクトリ

リソースクラスをこちらにも掲載します。 ちょー簡単な例ですが、こんな感じでリソースメソッドの引数にOptionalを使えるようになります。

package example;

import java.util.Optional;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.MediaType;

@Path("hello")
public class HelloWorld {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String say(@QueryParam("name") Optional<String> name) {
        return "Hello, " + name.orElse("world") + "!";
    }
}

注意点としては先ほども書きましたがParamConverter実装クラスとParamConverterProvider実装クラスも 自前で準備しなくてはならない事です。 まあ、一度書いたら使い回せるはずなのでサクッと書いておきましょー。

今までこれが出来なかった理由

@QueryParamなどで注釈された引数へ渡される値はSingleValueExtractorのextractメソッドを 通るんですが、Jersey 2.13までのextractメソッドは「値がnullでなければParamConverterなどで変換、 nullなら@DefaultValueで設定された値を返す」という感じの実装になっていました。

その部分を抜粋します。

@Override
public T extract(MultivaluedMap<String, String> parameters) {
    String v = parameters.getFirst(getName());
    if (v != null) {
        try {
            return fromString(v);
        } catch (WebApplicationException ex) {
            throw ex;
        } catch (ProcessingException ex) {
            throw ex;
        } catch (Exception ex) {
            throw new ExtractorException(ex);
        }
    } else {
        return defaultValue();
    }
}

このロジックが原因でOptionalのParamConverterを書いてもnullが渡ってくるアレっぷりでした。

しかしこのextractメソッドはJersey 2.14で次のように修正されました。

@Override
public T extract(MultivaluedMap<String, String> parameters) {
    String v = parameters.getFirst(getName());
    try {
        return fromString((v == null && isDefaultValueRegistered()) ? getDefaultValueString() : v);
    } catch (WebApplicationException ex) {
        throw ex;
    } catch (ProcessingException ex) {
        throw ex;
    } catch (IllegalArgumentException ex) {
        return defaultValue();
    } catch (Exception ex) {
        throw new ExtractorException(ex);
    }
}

ご覧の通り「値がnullかつデフォルト値が設定されていればデフォルト値を、 そうでなければ値をParamConverterなどに渡す」という風になっています。

これで値がnullの場合でもParamConverterを通るようになり、Optionalへの変換が可能になりました。

まとめ

• Jerseyでリクエストパラメータなどの受け取りにOptional使えるようになって嬉しい
• ハイテンションでブログ書いたら文章やばい

そんな感じでー

今日のコード

• https://github.com/backpaper0/sandbox の kotlin-staticmethod-example ディレクトリ

@AssertTrueでバリデーション

件の相関バリデーションはたぶんこんな感じです。

public int from;

public int to;

@AssertTrue
public boolean isFromLessThanTo() {
    return from < to;
}

私は、これは

• メソッド内にバリデーションロジックを書くので再利用性が低い
• @AssertTrue、そしてbooleanは宣言的ではない

と思っています。

じゃあ、どうすればいいのか

from < to を検証するアノテーションとカスタムバリデータを作りましょう。 そしてそれを付けるメソッドはbooleanではなくタプル(のような何か)を返します。

public int from;

public int to;

@FromLessThanTo
public Pair isFromLessThanTo() {
    return new Pair(from, to);
}

こうする事で、

• バリデーションのロジックはカスタムバリデータに閉じ込めたので再利用性高まる
• アノテーションで大小関係があるって分かって宣言的っぽい

となるかと。

そもそも

アノテーションを使ったバリデーションってどうなんでしょうね？

例えば、次のようなコードがあったとします。

@Isbn
public String isbn1;

@Isbn
public String isbn2;

アノテーションを見ればisbn1もisbn2もISBNであるということは分かるのですが、 でもそれってアノテーションの役割じゃなくて型じゃないの？と思うのです。

本来あるべき姿はこんな感じ。

public Isbn isbn1;

public Isbn isbn2;

この場合バリデーションはIsbn型へ変換するときに行うのが良いと思われます。

型よ

基本的にバリデーションは次の順番で行われると思います。

• 必須バリデーション
• フォーマットバリデーション(日付とされる値がyyyy/MM/ddになっているか？みたいなことです)
• 相関バリデーション

必須バリデーションを行うか否かも型で表したい。 Optionalでないものは必須！という感じです。 たぶんそれが良いと思う。

//必須
public Isbn isbn1;

//必須でない
public Optional<Isbn> isbn2;

フォーマットも先述の通り型で表す事ができます。

それから相関バリデーションですが、最初の例であればRangeといった型を作ってそこにfromとtoを 詰め込めばfromとtoの大小関係を型で表す事ができます。

new Range(from, to);

まとめ

まとまりません！ もっと理想的なバリデーションフレームワークが欲しい！

というわけでバリデーションへの悩みは尽きません。 悩ましい。

ビルドツール

昨今はGradleが人気のような雰囲気漂っていますが、 Maven を使いましょう。

JerseyはMavenのprofileという機能を使っていてGradleではその辺のサポートがないっぽいのでたぶんしんどいです。

• 参考： JAX-RSをGradleでアレしたい - 日々常々

……と書きましたが最近のGradleはprofile対応してるようです。

JAX-RSを始める #javaee — 裏紙 http://t.co/mAX6m50PMd 現在はGradleもProfileに対応してます http://t.co/pHMXxcnt7T

— Nobuhiro Sue (@nobusue) 2014, 12月 1

というわけでサンプルにGradleのビルドファイルも追加しました。

Mavenのインストールはバイナリを任意の場所にダウンロードして bin ディレクトリにパスを通せばおkです。

ビルドファイルの準備

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.glassfish.jersey</groupId>
      <artifactId>jersey-bom</artifactId>
      <version>2.13</version>
      <scope>import</scope>
      <type>pom</type>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-server</artifactId>
  </dependency>
  <dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-jdk-http</artifactId>
  </dependency>
  <dependency>
    <groupId>org.glassfish.jersey.test-framework.providers</groupId>
    <artifactId>jersey-test-framework-provider-jdk-http</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>

dependencies {
    compile 'org.glassfish.jersey.core:jersey-server:2.13'
    compile 'org.glassfish.jersey.containers:jersey-container-jdk-http:2.13'
    testCompile 'org.glassfish.jersey.test-framework.providers:jersey-test-framework-provider-jdk-http:2.13'
}

コードを書く

まあ、この辺は適当に、足し算する簡単なやつで。

src/main/java/app/Calc.java を作ります。

package app;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.MediaType;

@Path("calc")
public class Calc {

    @Path("add")
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public int add(@QueryParam("a") int a, @QueryParam("b") int b) {
        return a + b;
    }
}

で、JUnitテストです。 src/test/java/app/CalcTest.java を作ります。

package app;

import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;

import javax.ws.rs.core.Application;

import org.glassfish.jersey.server.ResourceConfig;
import org.glassfish.jersey.test.JerseyTest;
import org.junit.Test;

public class CalcTest extends JerseyTest {

    @Test
    public void test() throws Exception {
        int c = target("calc/add").queryParam("a", 2)
                                  .queryParam("b", 3)
                                  .request()
                                  .get(int.class);
        assertThat(c, is(5));
    }

    @Override
    protected Application configure() {
        return new ResourceConfig(Calc.class);
    }
}

test-frameworkを使うととても簡単にJUnitテストを書ける事が分かると思います。

テスト走らせる

IDEから実行するかMavenで。

mvn test

簡単ですね！

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running app.CalcTest
11 30, 2014 10:55:12 午後 org.glassfish.jersey.test.jdkhttp.JdkHttpServerTestContainerFactory$JdkHttpServerTestContainer <init>
情報: Creating JdkHttpServerTestContainer configured at the base URI http://localhost:9998/
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.109 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

mainメソッドでサーバーを立てる

JUnitテストを走らせている事からもお分かり頂けると思いますが、 簡単にサーバーを立てる事もできます。

こんな感じ。

package app;

import java.io.IOException;
import java.net.URI;

import org.glassfish.jersey.jdkhttp.JdkHttpServerFactory;
import org.glassfish.jersey.server.ResourceConfig;

import com.sun.net.httpserver.HttpServer;

public class Server {

    public static void main(String[] args) throws IOException {
        URI uri = URI.create("http://localhost:8080/rest/");

        ResourceConfig rc = new ResourceConfig();
        rc.register(Calc.class);

        HttpServer httpServer = JdkHttpServerFactory.createHttpServer(uri, rc);
        Runtime.getRuntime().addShutdownHook(new Thread(() -> httpServer.stop(0)));

        System.out.println("JAX-RS started");
    }
}

アプリケーションサーバにデプロイする

GlassFishにデプロイする場合はdependencyのscopeをprovidedにしてWARファイルを作ってそれをデプロイすれば良いと思います。

Tomcatにデプロイする場合は jersey-container-jdk-http を消して、 jersey-container-servlet を追加してWARファイルを作りましょう。 こんな感じです。

<dependencies>
  <dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-server</artifactId>
  </dependency>
  <dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-servlet</artifactId>
    <scope>runtime</scope>
  </dependency>
</dependencies>

私はServlet APIに依存しないよう作る方がポータビリティが高そうで好きなのでscopeをruntimeにしています。 Servlet APIじゃんじゃん使いたい場合はscopeをcompileにしてください。

まとめ

というわけでJerseyを使用したJAX-RSの導入部分、如何でしたでしょうか？ 簡単ですよね？ 特にJava EEの一部なのにアプリケーションサーバがなくても簡単に使えるのが良いですよね！ね！

最後に、手前味噌ですがJAX-RSの参考資料を挙げておきます。

• JAX-RSとかの話
• DevLOVE関西「開発スターターキット」におけるJAX-RSの簡単な解説
• Jerseyをjava -jarで動かす

はー、これらの資料もJAX-RS 2.0にアップデートしないといけないなー（しろめ

簡単ですが、以上。

本題

さて、今回はこのブログの基盤となっているブログツール、 Tinkerer のカスタムテーマを作ってみました。 と言ってもゼロから作るようなセンスは皆無なので、組込みの modern5 というテーマをコピーして ウルトラ怪獣としょぼちむカラーを混ぜ込んでみました。

今後、もとのテーマに戻した場合を考慮してスクリーンショット貼っておきます。

ヘッダ、本文、サイドバーなどの構成や基本的なカラーリングは modern5 のままですが、 ヘッダの背景色とリンクの色を変えてしょぼちむカラーにし、ヘッダの背景画像とセクションの見出しに ウルトラ怪獣の絵をはめ込みました。 余談ですが、私はバルタン星人が好きです(V)o\o(V)フォフォフォ。

あと、ブログタイトルをしょぼちむのブログっぽくするためbefore疑似要素、after疑似要素で文章を足しています。 念のため書いておきますが、このブログのタイトルは「裏紙」です。

……といった所で、残念ながらだいぶ力尽きました。 己のHTMLちから不足、CSSちから不足、Tinkererちから不足などに凹みました。

まあやり過ぎるよりは良いかー、と言う感じでどうかひとつ！ このとおりだ！

まとめ

ここまで”しょぼちむカラー”の説明なし！

おまけ

セクションの見出しの前に出してるレッドキングがちょっとかわいく描けた気がするので もうちょい大きいサイズも置いておきます。

本編という名の出オチ

こちらのリポジトリをcloneして、

• https://github.com/backpaper0/sandbox

irofディレクトリに移動し gradlew run してください。

するとこうなります。

なんといろふさんが例外吐いて終了しました！ (-∧-；)　ﾅﾑｰ

投げっぱなしの解説

Java言語ではメソッド名に空白や記号を使えませんがクラスファイルとJVM的にはもうちょい制約緩いっぽいので その辺を利用してスタックトレースでいろふさんを描きました。

いろふさんのアイコンからAAを作ったのは次のサービスです。

• http://www.text-image.com/convert/ascii.html

で、クラスファイルを書き出したのはASMというライブラリです。

• http://asm.ow2.org/

ASMの ClassWriter と GeneratorAdapter を使えば割と簡単にクラスファイルを書き出す事ができます。 詳しくはGeneratorAdapterのJavadocと今回のいろふソースコードを参照ください。

それと今回は使っていませんが ClassReader を使うとクラスファイルを読む事ができます。

例えばインスタンスメソッドを実行してるコードを見つけて標準出力に書き出すようなアレは次のように書けます。

ClassReader reader = new ClassReader("irof.Irof");

MethodVisitor methodVisitor = new MethodVisitor(Opcodes.ASM5) {

    @Override
    public void visitMethodInsn(int opcode, String owner, String name, String desc, boolean itf) {
        if (opcode == Opcodes.INVOKEVIRTUAL) {
            System.out.printf("owner=%1$s name=%2$s desc=%3$s%n", owner, name, desc);
        }
    }
};

ClassVisitor classVisitor = new ClassVisitor(Opcodes.ASM5) {

    @Override
    public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {
        return methodVisitor;
    }
};

reader.accept(classVisitor, 0);

ちなみにASMはJDKにも入っています。 rt.jar の com.sun.xml.internal.ws.org.objectweb.asm 以下がそうですね。 JAX-WSに使われているようです。

あと jersey-server にも使われています。 jersey.repackaged.org.objectweb.asm 以下がそうです。

まとめ

いざやってみるとすんなり出来ちゃって変態度が低すぎてアレですが、まあいいか。

細かい感想・気になった点など

というわけで細かい部分を挙げていきます。

• 29ページ。

  通常の業務システムを開発する中でアノテーションを作成することは少ないので”

  CDIというものがあってだな（ry

• 30ページ。

  インナークラスに名前付き定数を持てるの知らなかった。 勉強になりました！

• 34ページ、リスト19。

  複数コンストラクタを用意する場合、 オプション引数は後ろの引数(ここでいうと b )にする方が一般的と思います。

• 35ページ。

  例外オブジェクトには例外が発生した時の状態が詰め込まれてます。

  「状態」よりも「情報」の方がしっくりくるかなー。 前章で可変と不変について言及しているのも相まって分かりにくい気がしました。

• 38、39ページ。

  InvocationTargetException は他のリフレクション例外と意味合いがちょっと違うと思っています。 他のリフレクション例外が「指定されたメソッドを実行できなかった」のに対して InvocationTargetExceptionは「指定されたメソッドを実行中に例外が発生した」という状況です。 それによってハンドリングが変わるかどうかはケースバイケースとは思いますが。 あとここはマルチキャッチについて書いてて、たまたまリフレクション使っただけなので InvocationTargetExceptionの扱いとか関係無いか。 まあ気になったということで。

  気になったと言えば例外の中では InterruptedException の扱いにも注意が必要と思うので 言及しておいたほうが良いのではと一瞬思いましたが、 後のほうでマルチスレッドはうかつに触るなって書いてあるしまあいいか。

• 43ページ。

  Java 1.7のtry-with-resources構文のために追加された Throwable#addSuppressed(Throwable) も使えそうですね。

• 68ページ、リスト6。69ページ。

  Files.lines() をtry-with-resourcesでクローズしてるのは流石だと思いました。 ここはハマりどころになりそうな気がしますねー。

• 87ページ、リスト5。

  ボタンの押下時にAjaxで処理

  “押下”の現場感すごい。

• 95、96ページ。

  JAXB経由のJSONプロバイダはJAX-RSの標準仕様ではない(ですよね？)から注意が必要ですね。

• 98ページ、リスト3

  JPAにおけるReadとUpdate。 mergeはupdateではなくて永続コンテキスト外のエンティティを 永続コンテキストに突っ込む行為と思います。 em.find(clazz, id) したエンティティは永続コンテキストで管理されているので mergeする必要はないですよね？ ……とか思っていたら100ページでmergeの説明があった。

• 105ページ。

  モックによってテスト容易性を高めたり、

  具体例が欲しい気がしました。 CDIのalternativeはbeans.xmlを編集しなきゃいけなかったりして面倒い。 個人的にはCDIを使う場合はユニットテストにはGuiceを使うのが楽で良いと思っています。

あと、JVMへの言及が見当たらないのが気になりました。 -Xmx とか。

Java EEは、範囲が広くて仕様がでかいので仕方ないのですが、 内容が薄めだと感じてしまいました。 いっそJAX-RSやCDIなどの各仕様の説明はもっとシンプルにして、 チュートリアルを手厚くするという手もあったのかもかなー、などと無責任に思いました。

特にServletとEJBの説明はなくても良かったかも知れませんね。 すっぴんのサーブレットは使わないしEJBはトランザクション境界が欲しいってのが殆どと思いますし。 デカい案件やったことないので見当違いの意見かもしれませんが。

まとめ

というわけで、色々と細かいことも書きましたが総合的には間違い無く良書だと思っています。 冒頭にも書きましたがこの本は経験の浅いJavaエンジニアの皆様へオススメです。 この本を読んで学んで楽しいJavaライフを送りましょう！

あなたと！

(続きははてなブックマークのコメントでお願いします)

執筆陣のブログエントリ

まだ買ってないひとはキクタローさんのブログのアフィリンクから買おう！

• http://kikutaro777.hatenablog.com/entry/2014/11/03/191215
• http://d.hatena.ne.jp/irof/20141104/p1
• http://d.hatena.ne.jp/bitter_fox/20141111/1415687739
• http://d.hatena.ne.jp/nowokay/20141114

他の書評

• http://vividcode.hatenablog.com/entry/book/java-engineer-dokuhon

普通のJavaで末尾再帰最適化

最初からセミコロンレスJavaで考えてもしんどいだけなので、 まずは普通のJavaで末尾再帰最適化版のコードを書いてみます。 実装するに当たって 「Javaによる関数型プログラミング」 の7章を参考にしました。

import java.util.Optional;
import java.util.stream.Stream;

public class TailCallOptimization {

    public static void main(String[] args) {
        int n = Integer.parseInt(args[0]);

        F sum = (f, p, r) -> p < 1 ? done(r) : call(() -> f.apply(f, p - 1, r + p));

        TailCall t = sum.apply(sum, n, 0);

        Integer result = Stream.iterate(t, TailCall::get)
                               .map(TailCall::result)
                               .filter(Optional::isPresent)
                               .map(Optional::get)
                               .findFirst()
                               .get();

        System.out.println(result);
    }

    interface F {

        TailCall apply(F f, Integer p, Integer r);
    }

    static TailCall call(TailCall t) {
        return t;
    }

    static TailCall done(Integer result) {
        return new TailCall() {

            @Override
            public TailCall get() {
                throw new UnsupportedOperationException();
            }

            @Override
            public Optional<Integer> result() {
                return Optional.of(result);
            }
        };
    }

    interface TailCall {

        TailCall get();

        default Optional<Integer> result() {
            return Optional.empty();
        }
    }
}