Furyu

[フリュー公式] Tech Blog

フリュー株式会社の技術ブログです

2016年11月21日

sakata

弊社フリューはJJUG CCC 2016 fallのゴールドスポンサーになりました!

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

弊社フリューはJJUG CCC 2016 fallのスポンサーになりました!

http://www.java-users.jp/ccc2016fall/

JJUG CCCは毎年2回、春と秋に開催する日本最大のJavaコミュニティイベントです。Java関連の技術や事例に関する良質なセッションが行われ、また異なる分野で活躍するJava技術者が一堂に会する場ともなっています。

スポンサーにはダイヤモンド、プラチナ、ゴールド、ブースと種類があり、フリューはゴールドです。

CCCでは弊社から2セッション!

弊社では2セッションでスピーカーをします。

  • 13:30-14:20
  • ルームE
  • 10年運用している画像サービスでのJavaの活用と今後の展望

こちらは、盛岡が弊社のサービス開発について話します。私がCCCの2016 Springと2015 Springで話した弊社のサービスについて、別の観点から話します。盛岡はこのサービスを初期(10年前!)から担当しており、ユーザの拡大につれて変遷してきたアーキテクチャや運用、チーム構成などさまざなまリアルが聞けます!

  • 18:30
  • ルームI
  • バイトコードが君のトモダチになりたがっている

こちらは私のセッションです。Javaにおけるバイトコードって何?というところからそこを変更するライブラリの紹介、実例としてJava Agentでのバイトコード操作といったことを話します。

ぜひ私たちのセッションに足をお運びください!

エンジニア募集中

弊社では他にもScalaMatsuri、Scala関西 Summit、try! Swiftなどのスポンサーをしています。それもこれも最終的にはエンジニアの採用のためですね。京都での開発業務(Webアプリ、iOS/Androidネイティブアプリ)に興味のある方はぜひご連絡ください。

http://mobile-career.furyu.jp/

京都以外に渋谷にもオフィスがあり、開発をしています。関東の方もぜひご連絡ください。


2016年11月15日

SatoKeita

JMockitを使ってテストを書いていて困った点

こんにちはフリューのジョンです。普段はJMockitを使ってテストコードを書いているのですが、今回は、そのJMockitを使ってテストを書いていて、困った2点を書きたいと思います。

  1. すでに@Injectableで書いてあるクラスをモックしたい
  2. FileOutputStreamをJMockitでMockUpを使ってコンストラクタをモックする

この2つです。例えば以下のようなメソッドをテストした場合はどうすればよいのかを書きます。

環境

JDK 1.8.0_65
JMockit 1.18
JUnit 4.12

解説

1. すでに@Injectableで書いてあるクラスをモックしたい

これは、テスト対象のクラスに@Resourceがあるため、@Injectableを書いているため起きます。
@Mockedを引数に書いてつかうこと、MockUpを使ってやることもできません。(すでにモックされています、というエラーが出ます)

対応としては、ソースコードの①にある通り、Expectationsにクラスを渡すことで、Fileのモックを対象のExpectations内で書くことができます。
今回はコンストラクタをモックしたかったので、返り値となるFileのモックオブジェクトを@Injectableで定義してExpectations内で使用しています。

2. FileOutputStreamのコンストラクタをモックする

これはFileOutputStreamに@Mockedをつけてモックすることができないために起きます。(@Mockedは使えません、代わりに@Injectableや部分モックを使ってくださいというエラーが出ます)

対応しては、ソースコードの②にある通り、MockUpで記述します。
closeメソッドもモックしているのはtry-with-resource文にて自動的にcloseメソッドが呼ばれるためです。(もちろん無いとテストが落ちます)

ここで気をつけることが、一点あります。
実際のコードでは、ファイルを引数としたコンストラクタを使用していますが、テストコードでは異なるコンストラクタをモックします。理由としては以下になります。

To mock the target “FileOutputStream(File)” constructor, JMockit must replace the internal call to another constructor (“this(file, false);”) with an innocuous “super(…)” call. This is because, inside a constructor, the JVM forbids extra calls before a “super(…)” or “this(…)” call is complete. So, in this case calling “proceed()” from $init has no effect since there is no remaining code in the original constructor.

https://groups.google.com/forum/#!topic/jmockit-users/EvTuJKTecDk

意訳すると、以下のようになります。

JMockitでFileOutputStream(File)をモックするためには、内部でsuperによってFileOutputStream(File, false)を呼び出しているのでそちらをモックしてください。 理由としては、JVMによってsuper(…)またはthis(…)の余分な呼び出しが解消されます。だから、MockUpのproceed()で呼ばれる$initは存在しないコンストラクタを参照してしまうのです。

まとめ

JMockitは複数の書き方ができますが、それ故にわからなくなることも多いと思います。
みんな細かい部分で詰まっていると思いますので、ソースコードを共有していければ解消できるかもしれないですね(切実)


2016年10月13日

sakata

JavaOne 2016 サンフランシスコに参加しました!(その4) #javaone #j1jp

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

前回はコレクションのセッションについてのレポートでした。今回はクラスローダーのセッションについてレポートします。

Join the War on ClassLoader Leaks

スライドはこちらにあります。

https://static.rainfocus.com/oracle/oow16/sess/1461358415846001E0TZ/ppt/Classloader%20leaks%20public.pptx

内容

java.lang.OutOfMemoryError(OOME)はみな出会ったことがあるだろう。Java 8になってPermGen spaceとは出なくなったが、代わりにMetaspaceが出るようになった。ローカルでの開発時にも、継続的デプロイでもOOMEは出る。このセッションのアジェンダは次のようなものだ。

  • OOMEは何を意味するのか?
  • OOMEはなぜ起こるのか?
  • どこでリークするのか?
  • どのように避けるのか?
  • OSSの例
  • トレーニング

OOMEは何を意味するのか?

JVMのメモリはヒープとPermGen/Metaspaceとスタックである。スタックはスレッドごと、ローカル変数やメソッドのパラメータを持つ。ヒープはオブジェクトのインスタンスを持つ。PermGen/Metaspaceはjava.lang.Classインスタンスなどを持つ。PermGenという名前はJava EEとクラスのアンロードができる前に名付けられた。Java 8でMetaspaceへ置き換えられた。OOME PermGen space/Metaspaceは、あまりに多くのクラスをロードしたときに起こる。

OOMEはなぜ起こるのか?

OOME PermGen space/Metaspaceが起こる原因は次の2つが考えられる。

  1. アプリケーションが大きすぎる。Java 7までは-XX:MaxPermSize=256Mなどと指定すればよい。Java 8ではMetaspaceは自動的に増えていく。
  2. java.lang.Classインスタンスが再デプロイ後にガベージコレクトされない

参照の型は次の4つがある。

  • 強い参照:到達可能なときは決してGCされない
  • ソフト参照:OOMEになる前にGCされる
  • 弱い参照(WeakHashMap):強い参照とソフト参照がないときにGCされる
  • ファントム参照:GCは妨げない

GCの到達可能性は以下の図のようなことである。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-40-30

再デプロイでは、新しいWARファイルをデプロイすれば前のクラスローダはGCされる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-43-30

クラスローダーの参照は次の図のようになる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-44-55

どのようにリークが起きるのか。GCルートからクラスローダへ到達可能だと、クラスローダをGCすることができない。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-05-17-45-38

どこでリークするのか?

Tomcatなどアプリケーションサーバのバグだ。他にCommons LoggingやLog4Jなどロギングフレームワークのバグ、Bean Validation APIやUnified Expression Languageのバグといったこともある。

GCルートでも起こる。まず、システムクラスローダによってロードされるクラス。JDKのクラスにおけるstaticフィールドで起こる。ライブスレッドではローカル変数、メソッドのパラメータのスタック、java.lang.Threadインスタンスで起こる。

システムクラスでは、java.sql.DriverManagerやBean introspectionのキャッシュ、シャットダウンフック、カスタムでデフォルトにしたAuthenticator、カスタムのセキュリティでのProvider、カスタムMBean、カスタムのThreadGroup、カスタムのプロパティエディタ…最初の呼び出し元でのcontextClassLoaderへの参照などで起こる。

DriverManagerをもう少し詳しく見てみよう。たとえばMySQLのJDBCドライバを使うときはこうするだろう。

com.mysql.jdbc.Driverクラスにはstaticイニシャライザがある。

registerDriver()メソッドは以下のようになっている。

このregisterDriversという変数は、以下のものだ。

図で表すと以下のようになる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-16-55-03

そのため、コンテキストのシャットダウンで以下のように書かなければ、リークしてしまう。

スレッドもここで止めておかなければならない。次のようにスレッドを実装するのは悪いアイデアだ。

止められるようには以下のようにする。

このことは、次の記事に紹介されている。

Heinz Kabutz / Java Specialists’ – The Law of the Blind Spot

次にThreadLocalについて考えてみよう。次のように実装してはならない。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-09-13

ThreadLocalのJavaDocには以下のようにある。

Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; …

各スレッドは、スレッドが生存していてThreadLocalインスタンスがアクセス可能である間は、スレッド・ローカル変数のコピーへの暗黙的な参照を保持します。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-13-40

プールされたスレッドではスレッドはクラスローダより長生きする。ThreadLocalはThreadGlobalになる!

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-17-35

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-06-17-18-20

ThreadLocalMapのJavaDocには以下のようにある。

However, since reference queues are not used, stale entries are guaranteed to be removed only when the table starts running out of space

(私訳)しかしながらリファレンスキューが使われないので、テーブルが容量不足になり始めたときだけ失効したエントリが削除されることが保証されます。

参照を含んだカスタムの値は、staticなThreadLocalであればリークし、そうでなければ予測されていないGCとなる。カスタムのThreadLocalであればリークしない。

ThreadLocalはクリアするようにしよう。

実際には、多くのOSSライブラリが違反している。

どのように避けるのか?

リーク防止のライブラリがある。アプリケーションサーバ非依存、Tomcatよりも多くをカバーしており、ログで警告を出力、ライセンスはApache 2ライセンスだ。実行時の依存は0で、設定は必要ない。Mavenであれば以下のように依存ライブラリを追加する。

これはServlet 3.0以降用だが、2系のものもある。

OSSの例

Bean Validationの1.0.0.GAでは以下のようになっていた。

(私訳)List<ValidationProvider>はキーであるクラスローダに強い参照を持っている。JPAのCachingPersistenceProviderResolverと同じモデルを使うようにして。

jyukutyo調査

Bean Validationの1.1.0.GAではこのクラスは次のようになっています。

providersPerClassloader.put( classLoader, new SoftReference<List<ValidationProvider<?>>>( providers ) );とあるので、ソフト参照を使うようになったようです。

JPAのCachingPersistenceProviderResolverクラスも調べてみました。

その他のOSS

javax.el.BeanELResolverやorg.apache.cxf.transport.http.CXFAuthenticator、com.sun.star.lib.util.AsynchronousFinalizerも該当する。

トレーニング

Eclipse Memory Analyzer(MAT)を使おう。

http://www.eclipse.org/mat/

次のオプションをつけてアプリケーションを実行しよう。

感想

最後に出てきた、MATについてはこのブログで私が記事を書いています。

ヒープダンプをEclipse Memory Analyzerで解析しよう!

セッションとしては非常におもしろかったです。とくにOSSの実例を挙げながらリークの原因を解説する箇所ではとても興奮しました。こういう内容のセッションはJavaOneだと他にもいろいろとあります。なかなか普段の勉強会でこの分野を扱っていることは少ないと思いますので、興味がある人にはJavaOneはとても楽しめるカンファレンスです!


2016年10月12日

sakata

JavaOne 2016 サンフランシスコに参加しました!(その3) #javaone #j1jp

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

前回はAngular 2とGWTのチュートリアルセッションをレポートしました。今日はJDKの開発者であるStuart Marksさんのセッション”Collections Refueled”をレポートします。

Collections Refueled

スライドはこちらにあります。
https://stuartmarks.files.wordpress.com/2016/09/collectionsrefueled-final.pdf
タイトルの通り、Javaのコレクションフレームワークについての話です。その歴史とJava 8での拡張、Java 9での拡張と将来の作業についてでした。

内容

JDK 1.0はレガシーコレクション、VectorやHashtableなどである。1.2はコレクションフレームワークが導入された。インタフェースとしてCollection、List、Set、Map、Iteratorが、具象クラスとしてArrayList、HashSet、HashMap、TreeSet、TreeMapがある。5.0ではジェネリクス、java.util.concurrentパッケージが追加された。

Java 8

Java 8ではラムダとストリームが追加され、インタフェースにデフォルトメソッドとstaticメソッドが定義できるようになった。15年経って初めての変更だ。

 


CollectionはIterableのサブインタフェースなので、これはすべてのコレクションで動作する。
Iteratorインタフェースでは、ほとんどのイテレータは削除をサポートしていない。そのためこう書く必要があった。



remove()のデフォルトメソッドがまさにこれだ。削除できないイテレータを作るときは、単にremove()を省くだけでよい。削除できるものを書くときは、remove()メソッドをオーバーライドするだけだ。

Collectionインタフェースでは、removeIfでバルク更新ができるようになった。


もしコレクションがArrayListなら、7の場合の計算量はO(n^2)であり、8の場合はO(n)となる。

List

ListインタフェースのreplaceAllもバルク処理だ。


ただし、要素の型を変更することはできない。そうしたいときはStreamを使う。

List.sortはCollections.sortよりなぜよいのか?Collections.sortは3つのステップを使う。

  • 一時的な配列にコピーする
  • 配列をソートする
  • リストにコピーして戻す

List.sortはデフォルトでは上記と同じだが、ArrayList.sortはオーバーライドしてin-placeでソートするため、コピーはしない。Collections.sortは現在単にList.sortを呼び出すだけだ。

Map

MapインタフェースにもforEachがある。



replaceAllもある。



Java 7までMulti-mapはとても扱いづらかった。Multi-mapはキーに対して複数の値があるマップだ。

Java 8ではこうなる。

Comparator

Comparatorを書いて楽しい人はいる?Comparatorは多くの条件とコードの繰り返しだ。Java 8はComparatorにstaticとデフォルトメソッドを追加した。名字とnullがある名前でソートし、nullを最初に持ってくる2レベルのソートのサンプルを見てみよう。まずはJava 7から。

Java 8ではこうできる。

Java 9

JEP 269: Convenience Factory Methods for Collectionsだ。こういったAPIが追加される。

設計と実装の課題としては以下のものがあった。

  •  Immutability
  •  Iteration Order
  •  Nulls Disallowed
  •  Duplicate Handling
  •  Space Efficiency
  •  Serializability

新しいstaticファクトリメソッドが返すコレクションはイミュータブルとなる。これは従来の不変性であり、不変の永続性ではない(addなどはUnsupportedOperationExceptionをスローする)。不変性はよいものである。一般的な場合、コレクションは既知の値で初期化した後、変更することはない。不変であれば自動的にスレッドセーフになる。効率、とくにスペースについて改善するチャンスがある。JDKには一般的な目的のための不変コレクションはない。

Setの要素とMapのキーのイテレーションの順序については、HashSetやHashMapであれば公式には順序が保証されないとしていたが、長い間たいてい一貫していた。これを変更すると、順序に依存しているコードは動作が変わってしまう。適用するのは新しいコレクション実装だけにする。既存のコレクションは同じままとなるだろう。

ListやSetの要素、Mapのキーや値にnullを許可しない。NullPointerExceptionをスローする。1.2でコレクションにnullを許可したのは失敗だった。Java 5以降コレクションではnullを許可していない。とくにjava.util.concurrentのコレクションではそうだ。nullはNullPointerExceptionの原因だからだ。

Setの要素やMapのキーで重複したときはIllegalArgumentExceptionをスローする。”コレクションのリテラル”で重複があるのはプログラミングのエラーである可能性が高い。理想的にはこれをコンパイル時に検出する。値はコンパイル時の定数ではない。次にいいのは、実行時の生成においてフェイルファストにする。

2つの文字列の要素を持つSetを考えてみる。

どのぐらいスペースを使っているのか?オブジェクトを数えてみる。

  • unmodifiableなラッパーが1つ
  • HashSetが1つ
  • HashMapが1つ
  • 長さが3のObject配列のテーブルが1つ
  • Nodeオブジェクトが2つ、各要素に1つずつ

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-03-14-36-08

サイズの見積もりとしては、オブジェクトごとに12バイトのヘッダーがある(64ビットJVMで32GB未満のヒープ、OOP圧縮あり)。int、float、参照フィールドごとにプラス4バイトだ。ということは、先ほどのオブジェクトを合計すると152バイトになる。

 

  • unmodifiableなラッパー: ヘッダー + 1フィールド = 16バイト
  • HashSetが1つ : ヘッダー + 1フィールド = 16バイト
  • HashMapが1つ: ヘッダー + 6フィールド = 36バイト
  • 長さが3のObject配列のテーブル: ヘッダー + 4フィールド = 28バイト
  • Nodeオブジェクトが2つ、各要素に1つずつ: (ヘッダー + 4フィールド) * 2 = 56バイト

フィールドベースのSet実装だとオブジェクト1つとフィールド2つで20バイトとなる。

 

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-03-14-43-09

実装はすべてstaticファクトリの背後にあるプライベートなクラスとしている。

コレクションはすべてシリアライズできる。ただ、デフォルトのシリアライズ形式は内部実装について漏らしてしまっていた。新しいコレクションの実装は、カスタマイズしたシリアライズ形式となる。

将来的な作業

これらはまだ計画されていない将来的な作業だ。

VectorやHashtableといったレガシーなコレクションは非推奨にする。LinkedListもそうするかもしれない。

コアなコレクションのイテレーション順序をランダムにする。新しいミューテータのデフォルトメソッドを追加する。ArrayDequeへのインデックスアクセスを追加する。

JEP 269のコレクション拡張では、パフォーマンスの改善と、順序があるSet/Mapを追加する。

Project ValhallaでのValue typesなど。

感想

Stuartさんのセッションは熱い感じで印象深かったです。これはStuartさんの最後のセッションでしたが、他2つ、Stuartさんのすべてのセッションを聴きました。

このセッションの内容としては、Javaプログラミングで使わないことはほぼないであろう、コレクションについて歴史をたどれ、興味深いものでした。

JEP 269については、以前私は個人ブログにて動作確認していました。

そのためAPIの追加は知っていました。しかしほかにも数多くの改善があり、とくにコレクションが使うスペースについて理解が深まったのはうれしいです。


2016年09月30日

sakata

JavaOne 2016 サンフランシスコに参加しました!(その2) #javaone #j1jp

Hello world! コンテンツ・メディア第1事業部のjyukutyoこと阪田です。

前回の投稿ではJavaOneへの行き方を中心に書きました。今後数回に渡っていくつかのセッションの内容を紹介します。

Building Angular 2 Applications in Java 8

チュートリアルセッションです。Angular 2とGWT、Spring Bootでアプリケーションを作るには、という内容でした。スライドはこちらにあります。
http://lteconsulting.fr/angular2boot-javaone/#/
Angular 2とGWT 2.8を使う際の問題点と解決策が中心となっています。

内容

Angular 2はJavaScriptに加えてTypeScriptをサポートしている。Modules、Components、Dependency Injection、Change Detectionが基本的なものである。さらにJSR-269のPluggable Annotation Processing APIを使ってコードを生成する。バックエンドは、シンプルで強力なSpring Bootを使う。

GWTは今のWebからは遠いところにあるものなのは事実だ。GWTにあるものは、以下のもので置き換えられる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-12-59-15

ただ、GWT 2.8は将来の過渡期にある。

  • JsInterop
  • Java 8対応
  • Widgetや古いものをなくす

GWT 3はJ2CL (Java to Closure) となり、今標準となっている多くの機能をなくす。

GWTはモダンで最適化されたJavaScriptへコンパイルしてくれる。JsInteropはJavaScritpとJavaコード間を双方向で統合する。JavaScriptのXMLHttpRequestは以下のようなJavaクラスとなる。
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-13-16-14
これを次のように使うことができる。
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-13-16-27
そしてSuper Dev Modeには開発用の早いインクリメンタルなコンパイラがある。

JSR-269のPluggable Annotation Processing APIでは、独自のアノテーションプロセッサを登録する。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-13-23-34

そして、Angular2GwtというGWTとAngular 2を統合するライブラリを使う。 Angular2Gwtがすべてやってくれる。User moduleなしのGWTのコンパイルは早い。アプリケーションに依存ライブラリを1つ足すだけでできる。

アーキテクチャは次のようになる。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-13-28-11

デモアプリケーション

セッションではデモもありました。デモのリポジトリはこちらです。
https://github.com/ltearno/angular2boot-demos

デモアプリケーションはいくつかあります。ここではセッションで実行していた”my-first-tree-orchard”を動かしてみましょう。

$ cd my-first-tree-orchard
$ mvn spring-boot:run

僕の環境ではjava.lang.IllegalArgumentException: Can not copy a non-root Methodが出ましたが、起動しました。http://localhost:8080/にアクセスすると、”Application is loading”が出た後、次の画面になります。

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-13-53-23

あとは”Roll 6 faces dice”ボタンを押せば動作します。

さて、target/generated-sourcesディレクトリを見ると、コードが生成されています。
%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-09-29-14-00-06
ライブラリがPluggable Annotation Processing APIを使って生成したコードですね。

このままではコンポーネントのテンプレートを変更しても、即座に反映されません。Super Dev Modeを使ってみましょう。spring-boot:runはしたままで、別のウィンドウを使って同じディレクトリで次のコマンドを実行します。

$ mvn gwt:run-codeserver
...
[INFO] Super Dev Mode starting up
...

Super Dev Modeが起動しました。画面をリロードします。”Compileing Application”と表示されるようになります。

最後に、起動時のjava.lang.IllegalArgumentException: Can not copy a non-root Methodですが、古いバージョンのSpring Loadedの問題のようです。angular2boot-demosディレクトリにある親pom.xmlのspringloadedを1.2.0から現時点で最新の1.2.6にすると、例外は出力されなくなりました。

感想

Angular 2にもGWTにもほとんど知識はありませんでしたが、おもしろいアプローチではあると感じました。現時点ですぐにJavaにすべてを寄せるアプローチを使う予定はないのですが、こういった方法もあることは知っておいてよいですね。