エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

レガシーコードを JDK 8 でビルドしようとしたら "The system is out of resources" が出た話

今までJDK7でビルドされていたJavaプログラムをJDK8でビルドしようとしたところ、コンパイル時にこんなエラーが出ました。

The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
	at com.sun.tools.javac.code.Type.hasTag(Type.java:112)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1967)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571)
	at com.sun.tools.javac.code.Types.asSuper(Types.java:1952)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1968)
	at com.sun.tools.javac.code.Types$13.visitClassType(Types.java:1955)
	at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:786)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:4571)
	at com.sun.tools.javac.code.Types.asSuper(Types.java:1952)
	at com.sun.tools.javac.code.Types.unboxedType(Types.java:3987)
	at com.sun.tools.javac.code.Types.unboxedTypeOrType(Types.java:3998)
	at com.sun.tools.javac.comp.DeferredAttr$ArgumentExpressionKind.standaloneKind(DeferredAttr.java:1135)
	at com.sun.tools.javac.comp.DeferredAttr$DeferredChecker.visitLiteral(DeferredAttr.java:1296)
	at com.sun.tools.javac.tree.JCTree$JCLiteral.accept(JCTree.java:2037)
	at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
	at com.sun.tools.javac.comp.DeferredAttr$FilterScanner.scan(DeferredAttr.java:913)
	at com.sun.tools.javac.comp.DeferredAttr.isDeferred(DeferredAttr.java:1100)
	at com.sun.tools.javac.comp.Attr.attribArgs(Attr.java:660)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1806)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
	at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:3226)
	at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1897)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:566)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1815)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1465)
        (以降、繰り返し)

事象
・チームで使っているJenkinsと私のマシンのローカルだと本事象が発生
・他の2人に、ローカルでビルドを試してもらったら正常ビルドできた

mavenビルド時にjavacのログを出す方法を見つけたので試してみる。

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>1.8</source>
        <target>1.8</target>
        <compilerArguments>
            <verbose/>
        </compilerArguments>
    </configuration>
</plugin>

http://stackoverflow.com/questions/2210005/config-maven-2-to-print-out-javac-commands-during-compile-phase

[checking xx.xx.xxxxx.xxxxx.xxxx..XxxxxXxxxxxXxxxx]


The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
	at com.sun.tools.javac.comp.Resolve.findIdent(Resolve.java:2104)

数回試したけど毎回同じクラスで落ちてる!

で、そのクラスを覗いてみると…

private static String SQL = new StringBuilder().append(LINE).append(
"SELECT XXXXXXXX        ").append(LINE).append(
"     , XXXXXXXXXXXXXXXX").append(LINE).append(
"     , XXXXXXXXXXXXXXXX").append(LINE).append(
"     , XXXXXXXXXX      ").append(LINE).append(
"     , XXXXXXXX        ").append(LINE).append(
"     , XXXXXXXXXXXX    ").append(LINE).append(
"     , XXXXXXXXXX      ").append(LINE).append(
"     , XXXXXXX         ").append(LINE).append(

 ※以降、400行ほど続く

800を超えるappendによって作られた超巨大SQL

こいつはくせえッー!ゲロ以下のにおいがプンプンするぜッーーーーッ!!

試しにごそっと削ってみたら…

private static String SQL = "";

あっさりビルドが通りました。

Java Day Tokyo 2016 参加レポート2 マイクロサービスについて #javadaytokyo

今回のもう一つの参加目的、

「マイクロサービスの実践例と、支援するようなJavaアーキテクチャについて」です。

 

モジュールによるマイクロサービス?

はじめに、「1-A Java SE 9 Overview」より。

Project jigsaw によるModulanizeの目的の一つは、「開発者が、マイクロサービスなアプリケーションを開発できるようにする」「デプロイできるようにする」ことだと話されていました。
(通訳と俺の日本語聞き取りが間違ってなければ)

これって、モジュールのjar単位でデプロイしていく運用を想定されてるのでしょうか。

ちょっと「俺の知ってるマイクロサービスと違う」感があるのですが、必要な(Javaで言うところの)APIだけが適切にexportsされているのであれば、安全にモジュールの差し替えも可能なのかな…
DDLをとっかえてるみたいでおっかないのですけど。

実践して分かったJavaマイクロサービス開発

続いて、谷本心氏による発表「実践して分かったJavaマイクロサービス開発」より。

実在する、レガシーでモノリシックなECサイトをマイクロサービスに解体していった体験記でした。

セッションの内容自体は後で資料公開されるそうなのでそちらを見ていただくとして、セッション中に出てきた、衝撃を受けた言葉を衝撃を受けた順にご紹介したいと思います。

アクセサとコントローラで共通のInterface(Javaの)を実装した話

Client側サービスのItemAccesssorクラスが、Itemサービスを呼び、ItemControllerクラスが起動するような仕組みの時に、
ItemAcessorクラスとItemControllerクラス双方に、ItemServiceというインタフェースを実装するようにした という話。

良かったこ

 ・依存がIDEのHierarchy検索で簡単に探せる
 ・おなじIFなのでコントローラをDIするとサービス間の結合テストJunitでできる!(なにこれすごい)

これ、おもしろい工夫だし実用的なのですが、
マイクロサービスのメリットの一つである、Polyglot(多言語性)完全に捨てる話で、すごい割り切りだなと思いました。

谷本さん曰く
「各サービス基盤が標準化されている方にメリットが有る」とのこと。
確かに、マイクロサービス化してサービスの数が増えたところで、いちいち選択言語は変えないでしょうから、Javaで統一する、と割りきった設計にするのは一理ありますね。
そしてその場合、Modelのクラスはなんとなく一緒のものを使いそうですが、アクセサとコントローラで同じIFを実装する、と言うのは考えたことがありませんでした。

AWSを使ってないとマイクロサービスのメリットが引き出しにくい

特にスケーリングについて言及されてました。高負荷の際にすぐにスケールできるような状況でなければマイクロサービスのメリットが得にくいのではないか、と。

私自身はマイクロサービスのメリットは、各サービスごとの凝縮度を上げる&サービス間の結合度を下げる ことで得られるメンテナンス性の高さが最大のメリットだと思っているので、クラウドでなければ意味が無い とまではいかないと思いますが、スケーリングし易い という恩恵は確かに受けずらいですね。

 

どうしてもAPIの設計が画面に引きずられる

その結果、APIは再利用性が低いものに。
結果、「フロントサービス」と「ドメインサービス」が分割され、「フロントサービス」が「ドメインサービス」を必要に応じて呼ぶようになった。

 

来た! これはまさにここ最近私も悩み続けていた点で、とりあえず落ち着いた結論もほぼ同じ感じ。

RESTfulなマイクロサービスを作ろうとすると、画面に必要なロジックがどうしてもどこかに必要になるんですよね。

 

Java Day Tokyo 2016 参加レポート1 今後のJavaの動向、特にJava9について #javadaytokyo

3年ぶりにJavaDayTokyoに参加しました。

今回の自分のテーマは2つ
・今後のJavaの動向、特にJava9について
・マイクロサービスの実践例と、支援するようなJavaアーキテクチャについて


前者については、Java8導入直前にSan FranciscoでのJavaOneに参加させてもらった時に感じた、以下の気付きによります。
「いざ導入となった時にその素晴らしさを理解し、メンバー全員で使い始めるには、ある程度の事前知識を、自分はもちろん、メンバー皆が持っていることで、導入のハードルを下げることができるだろう」
http://taichiw.hatenablog.com/entry/2013/10/01/065607

(とは言え、いろんな外的要因があって、実際に自分のチームでJava8を使いはじめるまで2年はかかりましたが…)


後者については、今まさに日々、サービスの切り方やら作り方やらについて悩んでいるところなので、なにかヒントがあればなーという思いでした。


この記事では前者、「今後のJavaの動向、特にJava9について」に関わるところをご紹介したいと思います。

Cloud

Keynote および 「1-A Java SE 9 Overview」を聞いて、「クラウド」を非常に意識していると感じました。


Java9、及び今後Javaが注力することとして挙げられていたことの多くが、クラウドでの利用へ繋がっているようでした。
・セキュリティ
 → クラウド上で動かすならセキュリティが重要である
 Java9での実装としては、モジュール化による隠蔽があたる。PublicがPublic過ぎる問題を解決。
 
・Density(密度)
 必要なもののみを含むアプリケーションの動作。
 → メモリフットプリントを削減。クラウド上では数%の効率化が、何万ドルものコスト削減に繋がる。
 Java9での実装は同じくProject Jigsaw関連。Javaのランタイムコアrt.jarが小さなモジュールに解体され、必要な物だけ使用してアプリを作ることができるようになった。
 また、jlink(http://openjdk.java.net/jeps/282)により、Custmoized JREを作成可能。実行に必要な機能だけ揃えた、小さなJREを作ることができる。
 
・Start upの速度
 クラウドにおいて、プロビジョニングが高速になったのでJVMの起動がボトルネックになっている。
 コンテナが数ミリ秒で作られるのに、JVMの起動に数百ミリ秒かかってしまっている。

などなど。

Project Jigsaw Module

Java9の目玉であるModuleについては、「A-2 Project Jigsawではじめるモジュール開発」で櫻庭さんが丁寧に背景、作り方、使い方を説明してくださいました。

実は、昨日の夜、「予習しとかんと明日絶対ヤバイ!」と思ってProject Jigsawでググッて出てきた記事が、まさに今櫻庭さんがItproに連載されているもので
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/040500010/?ST=upper
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/042000011/?ST=upper
http://itpro.nikkeibp.co.jp/atcl/column/15/120700278/050900012/?ST=upper
セッションの内容はかなり「これゼミに出てたところだ!」的でしたw


モジュールごとに内部APIを隠蔽できる考え方はとても良いのですが、
・そもそもマイクロサービス化が進んでいるので、1アプリケーションに含まれるクラスは減りつつある
・一方、周りを見れば(自分も含めて)残念ながら今のクラスやメソッドのpublic/privateすらちゃんと考えられてるのか怪しい
背景を考えると、これそこまでちゃんと使われるのかなぁ… と思ったり。

一部、Mavenのようなパッケージ管理ツールの代わりの機能になりそうですが、完全に置き換えられるものでもないですし…。

正直なところ

Java8のLambdaがパラダイムシフトすぎたので比較すると、ではありますが、
言語仕様的には「是非Java9を使いたい」、とはまだ思えてないのが正直なところでした。

パフォーマンス面を中心に攻めているようなので、こちらの効果に期待ですが、あまり現在のプロダクトでは困ってるところではないんですよね。

 

自分の理解が追いついていないところも激しくあると思うので、今日をきっかけに今後も情報をキャッチアップしていきます。

 

いずれにしても(一夜漬けとはいえ)予習して、最新の話が聞けて、とても良い日でした。

Baseball Play Study で話させていただきました! #bpstudy

昨年に続いて今年もLTさせていただきました。
 
 
去年話せてもらった頃はLTそのものに対する慣れが相当あったのですが、どうもここ最近は人前で話すことからご無沙汰気味…
 
技術的な話は、先日jshellの記事として記載したものです。

IntelliJ IDEAハンズオンに参加しました #ideahandson #jbugj

サムライズムさん開催の、IntelliJ IDEAハンズオンに参加してきました。

今月はあと一回、3月24日にも開催されるようです。
開催予定イベント一覧 - 株式会社サムライズム | Doorkeeper

 

まとめも兼ねて、特に「へー!」と思ったものをご紹介させていただきます。(使ってる人には常識なことなのかも…)

 

Shift2回押しの検索が強力

今までClass検索くらいにしか使っていなかったのですが、もっと「なんでも検索できる」機能です。

例えば、エディタの行番号表示はどこでONにすれば… というとき。

"line number"などで検索すると…

f:id:taichiw:20160312222349p:plain

その場でON/OFFの切り替えまでできちゃうよ!

 

また、キーワードの一致もとても柔軟。

「Get"なんとか”Timelineクラス」を探したいんだけど…という時は

f:id:taichiw:20160312222743p:plain

さらに『ght』でもGetHomeTimelineクラスが探せる!

f:id:taichiw:20160312222817p:plain

 

Live Templates と Postfix Completionが楽しい!

psvm と打って tab で public static void main(String[] args) メソッドが。

sout と打って tab で System.out.println() が自動的に入力されます。

 

さらに、

f:id:taichiw:20160312223224p:plain

あー 左に戻って返り値用の変数宣言しないと… というとき。

末尾に.varとつけてtabで…

f:id:taichiw:20160312223528p:plain

f:id:taichiw:20160312223443p:plain

宣言を自動補完!

 

同様に、
コレクションに .for と打てば for文が、
booleanに .if と打てばif文が自動的に生成されます。

 

Live Template, Postfix Completion ともに、非常に多くのものがデフォルトで登録されている上、独自のカスタマイズも可能です。

f:id:taichiw:20160312223906p:plain

f:id:taichiw:20160312223916p:plain

 

「巻き戻せるデバッガ」Chronon

デバッガを使ったデバッグをしている時に、「あー 行き過ぎたー!!」という経験、ありますよね。

そこでStep overどころかStep backwardを提供してくれるプラグイン、Chrononです。

IntelliJ IDEA 13.1 EAPのChronon Debuggerをお試しください! | JetBrains ブログ

本来は有償ツールですが、IntelliJ IDEAのUltimateを使っている場合は無償で利用可能とのこと。

 

普通のデバッガも強力

標準で付属しているデバッガも強力です。

ぱっと見わかりづらいのですがこの「電卓」ボタンを押すと起動できるEvaluater.

f:id:taichiw:20160312224729p:plain

単に変数の現在値を確認するだけでなく、例えば.toString()をつけてみるなどの評価「式」が記述可能。

さらに、= で代入文を書けば、変数値を任意の値に変更することも可能です。

 

おまけ:「保存」がない

IntelliJ IDEAは常にオートセーブのため、ほかのテキストエディタにあるような「保存」機能がないそう。

今までなんとなくCtrl+Sを打っていたのですが意味がなかったのですね…。

 

 

 

jshellを使ってみた

ちょっとしたプログラミングに、jshellを使ってみました。

jshellとは、Java9から導入される、簡易実行環境。REPLっていうらしい。Rubyでいうirbに相当します。


jshell JDK 9 quick peek

 

使ってみた感想。

良いところ

・ワンラインサクッと書いて動かせるのは便利。自分は未だにJava8のStreamAPIとかLocalDateとかうまく書けないので、一行単位でいろいろ試せるのはよかった

・/openコマンドで、ファイルに書き出してあるスクリプトが読み込めるので、スクリプト言語のような実行の仕方ができる。

 

使いにくいと思ったところ

・importが大変。IDEじゃなくて適当なテキストエディタで書いていたのだけど、いちいちパッケージを調べないといけない。

・/openコマンドで100行くらいのものを読むと、エラーがどこで起こっているのかわかりにくい。エラーの行番号が出ない。クラスを作り始めるともうわけわからん。

・jshellに限らず他のREPLもそうみたいなんだけど、メソッドチェーンを書きたければ改行前にドットを打たないとシンタックスエラーになる

 

などなどありまして、1-2行を試すのはいいけれど、100行くらいのものを動かしたかったら、おとなしくIDE使って書いて、junitでキックするなり、普通にmainメソッド作るなりして動かしたほうがいいのかなぁと思いました。

 

全然いいコードじゃないけどこんな感じ

https://github.com/taichiw/baseball/blob/master/201603pitcher/makecalendar.java

XP祭りに参加してきました 2 LTした/LT聞いた #xpjug

俺も!LT

昨年に続いて今年も発表させていただきました。

自分の中では痛恨の失敗作…
言いたいことを一つにまとめられていないのがずっと不安だったのですが、案の定、伝えたい事がうまく伝えられなかったのかな という感触です。

言いたかったこと

  • E2Eテストを作りこんで、リグレッション0にした (自動テストの話)
  • E2Eテストを作るのをフローにしたら、メンバーの意識が変わってきた (チームビルディングの話)
  • GUI作るチームに移って困ってる。誰か助けて (ヘルプがほしい話)

自分の中で本当に話したかったところはチームビルディングの話、しかも自分の中では、「エンジニアである自分」と「管理職である自分」が融合した瞬間だった という話なのですが、XP祭だしあんまりチームビルディングよりな話するのも微妙かなぁ… ということで、先ほどの「~融合した」みたいな話には触れず、自動テスト寄りにしてしまった結果、中途半端な話で終わってしまった感がありました。

 

そして! この後の方々のLTを聞いて、「LTとはこうであろう」というものをまざまざと突きつけられたのです。

ネタに走る必要はなかったけど言いたいことだけ詰め込んでもしょうがないなぁ… っていう、去年も思ったことをまたやってしまった。

修行不足ですね。

みんなのLT

まさかの一番バッターだったので、自分のが終わったあとは存分に皆さんの発表を楽しませていただきました!

f:id:taichiw:20150914003841j:plain


ぐっと来たものを紹介させていただきます!

スクラムマスター2ヶ月生がチームの自己組織化に挑戦して:川鯉 光起さん

奮闘記。「お試し期間」って話が出てきて、すげえわかるなー!って思いました。

私も新しいことをチームでやりたい時、「2週間だけやらせてください! ふりかえりの時にどうだった?って聞くから気に入らなかったらその時言って欲しい」 って何度かやったことがある。

 

タイトルからぶっ放しすぎだし、「これぞLT」を見せつけられたLTでした。

 

すごく良い発表でした。まさかの「総務」話。

KPTを使ったふりかえりで、どんどん良くなっていったっていう話。アジャイルプラクティスは開発以外にも使える。

発表者の方が、「細かいことは覚えていない → これってカイゼンが日常化しきたってこと」って言われていたのも印象的でした。

今は当たり前のようにやってることが、ふと振り返るとカイゼンの中で生まれてきたことで、ちょっと前までは全然やってなかったこと… って言うの、私も経験あります。

 

正のループと負のループが8の字になって… という話。

テストのコストが増えて云々の、負のループが表面化してくるところとか、そこからどうするのか!? とかすげー気になる…! のだけど懇親会いけなかったので話せず。

是非続き聞きたい。

 

てらひでさん 

デイリースクラムで、

昨日◯◯やりました → 今日も◯◯やります → 特に困っていることはないです

みたいな流れになって困るので(すげーわかる!)

昨日やってること → その中で困っていること → 今日やること

の順番で話してください! って言った話。

カイゼンネタのストックとしていただきました。ここぞというタイミングでこれ使ってみたい。

 

 

 

…ということで。

自分のLTの失敗も含めて、学ばなければいけないことが大量にあることに気付かされた一日でした。

 

前夜、緊急の深夜メンテで、果たして行けるのか!?という状況だったのですが、会社で3時間仮眠してから(会議室はなかなか快適でした)の強行参加、してよかった!