【書評】みんなのJava OpenJDKから始まる大変革期！ #minjava
技術評論社から最近のJavaの状況についてまとめた解説書が出ました。*1
光栄なことに献本をいただいたので、早速レビューをさせていただこうと思います。
紙版と電子版があって、電子版は技術評論社のサイト（Gihyo Digital Publishing）で買った場合はDRMフリーのpdf版およびepub版がダウンロードできます。AmazonではKindle版、楽天ではKobo版が買えるみたいです。この辺りのフォーマットは好みの問題もあるかと思いますが、Gihyo Digital PublishingはDRMフリーを貫いているので使い勝手がよくて重宝しています。
全体像
端的に言って、Java SEからJava EE、最近流行りのマイクロフレームワークまでを解説した本です。これを一冊読んでおけば、最近の動向は一通り頭に入ると思います。各章、この内容を聞くならこの人だろうと納得できる著者が名を連ねています。なぜそうなったのかといった背景にまで触れているので、初見でも理解しやすいかと思います。
広く浅く紹介することにフォーカスされているので、それぞれの技術に関する細かい解説は基本的にありません。この本はあくまで索引として、より深く知りたい人は、各解説の中で紹介されている情報ソースを辿るという使い方をするのがよさそうです。
第1章 - Java 9以降で起こった変化の総まとめ
著者は @kis と @shinyafox のコンビ。
Java 9からJava 14までの言語仕様・ライブラリの変化から、Project Valhallaの解説、JVMの変更やJDK付属ツールの紹介まで、全部ちゃんと解説したらそれだけで1冊できてしまいそうな内容が、ぎゅっと一章にん詰まっています。最近の動向が非常に簡潔まとまっているので、Javaを使っている人にとっては必読の章です。ちょうど今月リリースされるJava 14の新機能までちゃんと押さえられているあたりは、さすがきしださんといったところですね。
第2章 - JDKディストリビューションを選ぶときの指針になる章
著者はOpenJDK警察ソムリエこと @yamadamn 。
OracleがOracle JDKの商用機能をOpenJDKプロジェクトに寄贈し、ライセンス体系を変更したことによって、Java界隈ではJDKディストリビューションの群雄割拠時代が訪れました。それまでは何となくOracle JDKを使っていれば問題なかったわけですが、これからはプロジェクトで採用するJDKについて、ライセンスやサポート体制、個別機能の違いなどを考慮して、自分で選択しなければならないのです。
この章では、なぜそんな状況になったのかという背景をはじめとして、どんなJDKディストリビューションがあるのか、どういう観点で選べばいいのかなどが、具体的なJDKの名前を挙げながら紹介されています。各JDKの違いとか、事情を知っている人間が見てもややこしい。新しいプロジェクトに着手する際には、とりあえず手元に置いておきたい情報源になります。
第3章 - Java EE/Jakarta EEってどうなってるの？ってちょっとでも思ったらこれを読もう
著者は @khasunuma 。
前半は、エンタープライズJavaについて、これまでの成り立ちから、Java EE→Jakarta EEになった経緯までの解説。Java EEに興味がある人にとっては釈迦に説法的な内容にも感じられましたが、これまでの変遷をいま一度おさらいした上でJakarta EEに臨もうという人には非常に良いサマリーになっていると思います。
後半はJakarta EEについて。Jakarta EEで提供されるコンポーネントがAPI単位で紹介されているので、全体像を把握するのはとても良いです。特にJava EE 8とJakarta EE 8の対照表は要チェック。Jakarta EE 9以降についてはさらっと紹介程度ですが、これは現時点ではまだ不透明な部分が多いので仕方ないです。
第4章 - そしてMicroProfileの動向もおさえておこう
著者は第4章と同じく @khasunuma 。
MicroProfileはJava EEをベースとしたマイクロサービス向けのAPIセットですが、これが生まれた経緯や、具体的なAPIなどについて紹介されています。全体像を掴むにはいいですが、Java EE/Jakarta EEとの違いや、ユースケースの違いなどが、もっと分かりやすく比較されているともっと良かったかなと思います。
第5章 - 最近なにかと話題のGraalVMについて知りたいならここ
著者はJVMになりたい男こと @jyukutyo 。
GraalVMというとネイティブイメージ生成の部分で話題に上ることが多い印象がありますが、実際にはそれだけではなくて、マルチ言語基盤や、高性能なJITコンパイラなど、様々な顔を持った極めて汎用的なツールになっています。なので「GraalVMとは」ということを簡潔に説明するのはなかなか難しいのですが、この章では少ないページ数でそのあたりをわかりやすく説明してくれています。具体的な使用例が掲載されている点も、初めて触る人にとってはイメージが掴みやすくて良いと思いました。
第6章 - そろそろ軽量フレームワークも使ってみようかな、という人のための章
著者は @kencharos。
Javaのコア機能から少しはずれて「軽量フレームワーク」という点にフォーカスを当てている辺り、ほかの章とは毛色が違うかなと感じました。内容は、近年の動向から軽量フレームワークが登場した経緯や、押さえておくべき機能の概要を解説した上で、代表例としてタイトルにもあるMicronautとQuarkus、そしてHelidonという3つのフレームワークを紹介しています。
あくまでも第三者のユーザとしての目線されていて、強みは何かみたいな話というよりは、実際に使ってみるためのチュートリアル的な内容としてまとまっています。もう少し選択する上での基準みたいな話があってもよかったかなという感じもありますが、軽量フレームワークに触れる第一歩としては非常に良い参考文献になると思います。
*1:正式な発売日は2020年3月13日なので、本エントリーを書いた時点ではまだ先行販売期間でした。
Oracle Code One 2019の参加費の割引制度やホテル・飛行機を予約する際のポイントなど
Oracle Code One 2019（元Java One）の参加登録がスタートしています。
今年の日程は9月16日（月）から19日（木）までの4日間。例年通りOracle Open Worldとの併催で、会場も変わらずサンフランシスコのMoscone Centerです。
www.oracle.com
参加費は早く登録するほどお得
参加費には「General Full Conference」と「Group Purchase Discount」、「Government Rate」の三種類の形態がありますが、通常の個人パスは「General Full Conference」なので、間違えないように買いましょう。
「Group Purchase Discount」はグループパスで、5人以上の場合にかなりお得な値段で購入できますが、キャンセルできないなどの制限もあります。「Government Rate」は政府関係者向けです。
General Full Conferenceパスの価格は以下の通りです。
正規価格（On-site）は2050ドルですが、4月20日までに登録するとSuper Saverで1450ドル、7月6日までならEarly Birdで1650ドル、9月14日までは1850ドルと、早く登録すればそれだけお得に購入できる仕組みになっています。なので、参加する予定がある人は、4月20日までに登録しておいた方が断然お得です。
このパスには、キーノートを含む各セッションへの参加権のほか、4日間の昼食、カンファレンスバッグなどのお土産、Oracle CloudFest.という記念ライブのチケットが含まれています。
8月2日までは無料でキャンセルできる
いくら安いといっても9月の予定なんてまだ確定できないよ、という方も、ご安心ください。8月2日までであればキャンセルしても全額戻ってきます（為替レートによって多少の増減はあるかも）。
キャンセルポリシーはFAQのページに載っています。以下はその抜粋です。
8月2日までは全額返却、8月23日までは半額返却と書かれています。なお、5:00 p.m. PTというのは日本時間だと翌日
の午前9時です。
ほかに、CfPが採用されてスピーカーになった場合も全額返ってくるそうです。
とりあえずホテルを押さえよう
少しでも参加する気がある人は、参加登録はともかくとして、まずはホテルを押さえましょう。カンファレンス期間中のサンフランシスコのホテル代は年々高騰していて、会場に近くて比較的安いホテルは争奪戦です。とにかく早くしないとすぐ埋まってしまうので、今すぐにでも予約しておいた方がいいでしょう。その際、キャンセル可能の条件で探すのがポイントです。
Conferenceパスの購入と同時に、Conference割引が適用されるホテルを予約することもできます。海外旅行に慣れていない人は、これを利用するのが安心です。
もちろん、ホテルは個人で予約しても構いません。私はいつも、Hotels.comやBooking.com、Agoda.comなどを見比べながら安いホテルを探します。
ただし、サンフランシスコのダウンタウン（会場のある地域）は少しでも中心地から離れるとすぐ治安の悪い地区に突入してしまうので、土地勘の無い人は十分注意してホテルを探す必要があります。「テンダーロイン」や「SoMa」と聞いてピンと来ない人は、Conferenceおすすめのホテルにしておいた方が無難でしょう。
飛行機の予約は4月以降に
飛行機については、ホテルほど急いで予約する必要はありません。サンフランシスコの直行便は安くても15万くらいしますが、経由便であればもっと安く済ませることができます。
飛行機のチケット代で気にておいた方がいいのは燃油サーチャージです。ちょうど2月に値上がりしたばかりで、いまは北米便だと往復35000円もかかります。ただし、4月になるとこれが往復15000円になる見込みです。
多くの航空会社は、2ヶ月に1回燃油サーチャージの改定を行います。日本の航空会社の場合、4月の金額は、12月と1月のシンガポール・ケロシンの価格の平均値を基準に決めます。この2ヶ月間でガソリン価格がかなり落ちたので、燃油サーチャージも下がるというわけです。ただし、航空会社はこの差額をチケット代本体の値上げで調整したりするので、単純に2万円安くなるかというと、そういうわけでもありません。
なお、2月〜3月にかけてのガソリン価格は1月よりは若干値上がりしているので、6月には燃油サーチャージがまた少し（往復7000円くらい）上がる可能性もあります。いずれにせよ、4月になれば6月の改定の見込みが立つでの、様子を見ながら予約すればいいでしょう。
最後に
去年のOracle Code One報告会で、必要なお金を少しでも安く済ませるポイントについてLTしたので、そのスライドを貼っておきます。
www.slideshare.net
また、そのほかの参加のコツについてはじゅくちょーこと関Java会長の阪田氏のエントリーが参考になります。
JavaOne 2017 移動&滞在（もしくは海外カンファレンス参加Tips） #JavaOne #j1jp - Fight the Future
みんなでサンフランシスコに行って蟹食べましょう。
I talked about Java community events at JJUG CCC Spring 2018
Last month, I talked about a Java community for first time attendees at JJUG CCC 2018 Spring.
JJUG CCC is a Java community conference organized by Japan Java User Group (Usually, the group is called JJUG).
This is the presentation slide of my session but it is only in Japanese.
www.slideshare.net
I explained why the community activities are important for Java. And I recommended that if they want to increase their knowledge of Java, they should join in our community activities.
In addition, I talked about my experiences with some international Java conferences.
The Oracle Code One (the original name is JavaOne) is the most important Java conference organized by Oracle. The first time I participated in the JavaOne conference was 13 years ago. At that time, I didn't speak English well. However, I was still very much enjoyed the experience.
I remember that John Gage, a startup member of Sun Microsystems, said "Don't be shy!" on the stage of the keynote session. It was an important rule of the JavaOne conference. A lot of Java developer come from all over the world. It is a golden opportunity to discuss, share some know-how, communicate and make friends.
His saying "Don't be shy!" echoes still in my mind.
Last year, I participated in the JBCNConf 2017. It is annual Java community conference in Barcelona, Spain. I was the only one Japanese attendee. I tried to communicate with other participants in my broken English. It required courage. However, John Gage's words whispered in my ear: "Don't be shy!".
About 10 months later, I got a message from a developer who lives in London. We had met in Barcelona. He said that he was comming to Japan to have a session at the JJUG CCC. He remembered JJUG because I introduced him to it. I succeeded in making a friend.
I also introduced JOnsen. JOnsen is an unconference of Java in Japan. There were about 30 participants. Half were Japanese, Half were foreigners. So, the common language was English.
However, an organizer said "JOnsen is the most relaxed unconference". In fact, we were so relaxed. We discussed about not only Java technology but also culture, diversity, education and community. In addition, we also enjoyed some leisure activities such as hiking, drinking and karaoke.
About JOnsen, there is a good entry written by Matthew Gilliard.
Matthew Gilliard's blog || JOnsen 2018
At the end of my session, I called on all attendees to participate in these international conferences. Of course, English is important. But it is just a tool. The most important thing is the mind. We must accross borders and share our knowledge around the world.
JJUG CCC 2018 Springお疲れ様でした！#jjug_ccc #jjug pic.twitter.com/TBAYbBLLg5
— まめぴか＠⚔️🐻🐉 (@mame_pika) May 26, 2018
AndroidにおけるJava API使用の何がフェアユースではなかったのか
昨日の話の続きです。
nebuta.hatenablog.jp
Google翻訳に頼りながら判決文を眺めてみました。素人だし英語苦手なのでいろいろ誤解してるかもしれませんが、そのときはすみません。判決文の全文は以下に公開されています。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF
前提
ソフトウェアのAPIが著作権法の保護対象になるということは、2015年6月に最高裁判決が出ているので、残念なことですがこれはもう確定していました（正確には、2014年5月に控訴審判決が出て、Googleが最高裁に上告。翌6月に上告が棄却されて確定した）。
今回の争点は、「GoogleがAndroidにおいてJava APIを無断流用したことがフェアユースにあたるか否か」です。米国の著作権法上は、フェアユースであれば著作権の侵害には当たりません。そこでフェアユースだとした地裁の判断に対して、Oracleが不服を申し立てたのがこの控訴審です。
4つの争点
フェアユースか否かの判断材料として、今回は以下の4つ要素がおもな争点として取り上げられています（各要素については後述）。
- Factor 1: the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes
- Factor 2: the nature of the copyrighted work
- Factor 3: the amount and substantiality of the portion used in relation to the copyrighted work as a whole
- Factor 4: the effect of the use upon the potential market for or value of the copyrighted work
この4つのうち、Factor 1と4については"フェアユースではない"方向に、Factor 2については"フェアユースである"方向にそれぞれ有利で、Factor 3については中立的であると判断されています。
On this record, factors one and four weigh heavily against a finding of fair use, while factor two weighs in favor of such a finding and factor three is, at best, neutral. Weighing these factors together, we conclude that Google’s use of the declaring code and SSO of the 37 API packages was not fair as a matter of law.
(p.54)
ただし、Factor 2については"フェアユースバランシング全体に対してそれほど重要ではない"とも記されています。
The Ninth Circuit has recognized, however, that this second factor “typically has not been terribly significant in the overall fair use balancing."
(p.44)
これらを総合的に判断して、AndroidのJava API使用については"フェアユースではない"という結論に至ったとのことです。
Factor 1: The Purpose and Character of the Use
簡単に言えば、AndroidでJava APIを使っていることが商業的な性質が強いか否か、ということです。Oracleは、GoogleはAndroidで莫大な利益を上げているから商業的だと主張していて、GoogleはAndroidはオープンソースだしGoogleの利益は検索エンジンによるものだからAndroid自体は非商業的だと反論しています。これに対して控訴裁では、商業的か否かはその利益が金銭的であるかどうかや、直接的に得られるものであるかどうかに依存しないので、Androidは商業的であると結論付けています。
それからもうひとつの大きな論点として、"transformative"であるか否かということも挙げられています。transformativeという用語をうまく解釈できなかったのですが、どうやら新しい価値を与えるような使用方法かどうかということのようです。Oracleは、Googleは単にAPIをコピーしただけだからtransformativeではないと主張していて、Googleはスマートフォンという新しいプラットフォームを作ることが目的だったと反論しています。
地裁ではGoogleの"transformativeである"という主張は認められて重く評価されたようですが、控訴審にあたっては逆にGoogleの主張が退けられました。根拠としては、スマートフォンといえども同じAPIを同じ目的で使っていることに変わりはないことなどが挙げられています。
この控訴審にあたってOracleは、数千行のOracleのJavaコードがAndroidでそのまま使われているという証拠を提出していて、これも地裁の判断を覆す大きな材料になったようです。
Factor 2: Nature of the Copyrighted Work
APIを設計という行為が創造的なものであるかどうか、という争点です。まず、コンピュータソフトウェア自体は、著作権法で保護されるべき対象という前提はすでに確立されています。そして、APIパッケージの宣言コードとSSO(Structure Sequence Organization)が著作権法の保護対象だということはすでに結論が出ています。
その一方で、APIの宣言とSSOの創造性というのは”最小限のもの”であり、APIというのは創造的な側面だけでなく機能的な側面も重要であることから、これを使用することはフェアユースであるというのがGoogle側の主張です。地裁ではこの主張が認められ、控訴審でも肯定的に判断されました。しかし前述のように、それ自体が全体に対してあまり重要ではないとされています。
Factor 3: Amount and Substantiality of the Portion Used
元の著作物の量的および質的な価値はどれくらいのものか、という争点です。これについては、開発者の負担を軽減するために、既存のAPIを流用するという行為がAndroidプラットフォームを作るにあたって重要であったことはGoogleも認めています。
Factor 4: Effect Upon the Potential Market
AndroidがOracleが本来持っていたはずの潜在的な市場での価値をどの程度損ねたのか、という争点です。これは、フェアユースの「元の作品の市場性を著しく損なうことがないようなコピーに限定される」という考え方を反映したものだそうです。
Googleは、Oracleがデバイスメーカーではないことや、まだスマートフォン市場を開拓していなかったことなどを挙げて、AndroidがOracleの市場を奪ったことはないと主張しており、地裁もそれを認めていました。しかし控訴審では、スマートフォンがOracleの"潜在的な"市場であったことは疑いがなく、デバイスメーカーでないことも（自分で作らなくてもライセンス供与などの方法があるので）意味のない主張だという結論が出されました。
結局、APIはコピーしちゃダメなの？
これらの争点のうち、Factor 1/3/4については"Androidの場合"という前提での話であって、別のケースであれば違った判断がくだされる可能性もあるでしょう。要は、フェアユースと言い切るにはGoogleが儲けすぎていて、Oracleが進出して儲けられる可能性を奪ってるよね、という話です。Oracleの主張が認められた形ですね。
一方でFactor 2は、APIの宣言コードとSSOは（著作権法で保護されるべき）創造性を持っているけど、機能的側面も強いからフェアユース性もある、ということを認めています。ただし、それはフェアユースであるか否かを判断する他の要素に強い影響を与えるものではない、ということです。
もともとフェアユースかどうかは個別の事案で判断される性質のものなので、今回の判決だけですべてのケースが決まるというわけではありません。特に今回は、商業活動であるかや、潜在的な市場価値にどれだけ影響を与えたかということが決め手になっているので、この点が非常に大きな意味を持っていると思います。
AndroidによるJava APIの使用は著作権侵害に該当するという判決
詳しくないので間違いがあったらすみません。
米控訴裁判所が、Java APIの使用に関するOracleとGoogleの争いに新しい決定を下したようです。Oracleによる「GoogleのAndroidによるJava APIの使用はフェアユースには当たらず、同社の著作権を侵害している」という主張を認め、地方裁判所に損害賠償の裁判を差し戻すという判決が出されました。
Oracle wins appeal against Google in copyright case – TechCrunch
今回の判決
判決文は以下にあります。
http://www.cafc.uscourts.gov/sites/default/files/opinions-orders/17-1118.Opinion.3-26-2018.1.PDF
最後のConclusionに次のように書かれています。
For the foregoing reasons, we conclude that Google’s use of the 37 Java API packages was not fair as a matter
of law. We therefore reverse the district court’s decisions denying Oracle’s motions for JMOL and remand for a trial on damages. The district court may determine the appropriate vehicle for consideration of infringement allegations regarding additional uses of Android. We dismiss Google’s cross-appeal.私たちは、Googleの37のJava APIパッケージの使用は、法律上のフェアユースではないと結論づける。したがって、JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定を取り消し、損害賠償の裁判を差し戻す。（後略）
言葉通り、フェアユースではないということは著作権侵害にあたるということなので、最初の損害賠償請求の裁判に戻すよ、ということです。
これまでの経緯
OracleとGoogleの争いに関するこれまでの経緯は、2016年7月のJJUGナイトセミナーの様子をレポートした次の記事に詳しくまとめられています。
Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える（その１）。JJUGナイトセミナー － Publickey
重要な部分のみ抜粋すると、
- GoogleによるJava使用は特許侵害ではないという判決がでる（2012年5月）
- APIは著作権法で保護されるという判決がでる（2015年6月）
- GoogleのAndroidにおけるJava API使用はフェアユースにあたるという評決がでる（2016年6月）
最初の2つは、すでに判決が出てしまっているので確定事項です。また、2のAPIが著作権法で保護されるというのはJava APIに限定されたものではないので、非常に広範囲に影響するということで大きな話題になりました。
APIに著作権があるとしても、Androidにおける使用はフェアユースだから著作権法の保護の対象にはならないよ、としたのが3つ目の評決です。判決文のJMOL（Judgment as a Matter Of Law）というのがこの判断のことを指しています。
その後、Oracleは地方裁判所に対して新たな審理を求めましたが、2016年9月に棄却されています。これが「JMOLに関するオラクルの申し立てを棄却した地方裁判所の決定」というやつです。そのあたりの経緯やOracleの主張については、下記の記事で解説されています。
オラクル、グーグルによるJava APIの使用めぐり上訴 - ZDNet Japan
今回の控訴裁判所の判決では、"フェアユースに当たる"とした判断そのものが覆されたわけです。なぜ覆されたのかは判決文に書いてあるようですが、難しそうなので読んでいません。誰か読んで教えてください。
追記：
判決文をもう少しちゃんと眺めてみたので、こちらも参考にしてください。
AndroidにおけるJava API使用の何がフェアユースではなかったのか - 我らねぶた馬鹿
JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」に参加した話
3月26日（月）に開催されたJJUGナイトセミナー「Java SE 10 / JDK10リリース特集」に参加してきました。タイトル通り、先日リリースされたJava 10の新機能などについて特集する会で、参加者240人枠の予約がすぐに埋まり、さらにキャンセル待ち200人以上という盛況ぶりでした。やはりみんな関心があるんですね。
【東京】JJUG ナイトセミナー 「Java SE 10 / JDK10リリース特集」 3/26（月）開催 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper
どうでもいい話だけど、Java 10と書けばいいのか、JDK 10と書けばいいのか、はたまたJava SE 10と書けばいいのか未だに戸惑いますね。
新しいリリースモデルのおさらい
まずはオラクルの伊藤敬さん（@itakash）から、新しくなったJDKのリリースモデルに関するおさらいから。
もういろんなところで言及されているように、OSS版であるOpenJDKについては、年2回6ヶ月毎（3月と9月）のメジャーリリース、3ヶ月毎（1、4、7、10月）のパッチリリースというサイクルになります。原則として各バージョンでリリース期間は重複しないので、次のバージョンが出たらそれまでのバージョンは非サポートになりますが、3年毎にLTS（Long Term Support）版が出ます。直近のLTSは次のJDK 11です。
Oracle JDKは、次のJDK 11以降で新しいリリースモデルが適用されて、以降は有償版のみの提供となります。リリース間隔は3年ごとで、サポート期間はそれぞれ8年間。OpenJDKと同様に3ヶ月毎に（1、4、7、10月）パッチリリースが行われます。なお従来Oracle JDKの有償版にのみ提供されていた機能については、段階を踏んでOpenJDKに移行されるので、Oracle JDKとOpenJDKは同等の内容になります。
これまで無償版のOracle JDKを使っていたユーザは、Oracle JDKを有償サポートで使うか、OpenJDKに移行するかという選択を迫られています。非LTSなOracle JDK 8のサポート期限が2019年1月（個人利用の場合は2020年12月）なので、猶予はそれほどありません。
Oracle Java SE サポート･ロードマップ
ただし、これまでのOracle JDKも無償版に関してはOpen JDKと同等のものだったので、この機会にOpenJDKに移行してしまってもそれほど大きな問題にはならないと思っています。その場合、常に最新機能に追随して6ヶ月毎にアップデートを頑張るか、LTSで3年毎にアップデートするかという選択になりますね。
それよりも問題は、Java 8からJava 9にかけては多くの非互換性が含まれているので、Oracle JDK 8のサポート期限である2019年1月までに移行を完了させられるかということに尽きますね。これから始めるプロジェクトに関しては、Java 9以降（現実的にはJava 11）をターゲットにする想定した方がいいと思います。
JDK 10の追加機能の解説
続いて、David Buckさん（@DavidBuckJP）によるJDK 10に追加された新機能の解説。あとから資料が公開されるので細かい話は両略しまし（公開されたらリンクを追加します）。あと、Qiitaのきしださんの記事もよくまとまっていて分かりやすいです。
Buckさんの話の大部分は、JEP 286のローカル変数型推論についての話でした。いわゆる、Java版の「var」です。JDK 10以降では、変数の宣言時にvarを指定することで明示的に型を指定しなくてもよくなりました。これはあくまでもイニシャライザの型から自動的に静的型が推測されるだけなので、動的型とは全く違います。型を書かなくてもいいというだけで、内部的には型があります。
varが導入されたことで、Javaのコーディングスタイルは大きく変わる可能性があります。ということで、OpenJDKプロジェクトからvarを使う場合のスタイルガイドが公開されています。Buckさんの解説もこのスタイルガイドを元にしたものです。「Oracle Blogs 日本語のまとめ」に日本語訳があります。
Oracle Blogs 日本語のまとめ: [Java] Style Guidelines for Local Variable Type Inference in Java
ここでもっとも重要なのは、"varはコードの可読性を上げるために使う"ということだと思います。タイプ量を減らすといった目的ではなく、あくまでもコードをシンプルにして読みやすくするために使うということです。明示的な型宣言が無いとコードが読みにくくなりそうですが、実際にはコードを読めば何の型かはすぐに理解できるので問題なく、逆に可読性が上がるという結論が多くの言語で出ているそうです。面白いですね。
Java 10でぼくたちの生活はどうかわるのか
最後に、久保田祐史さん（@sugarlife）ときしだなおきさん（@kis）によるセッション。おもに、新機能や互換性などの情報をどう追っていったらいいかという話や、Java 10に移行する上ので注意点などに関する話。これも資料が公開されるそうなので、細かい話は省略します。
Java 10以降におけるアップデートの手順は
という感じにするのがいいそうです。非対応ライブラリの洗い出しには、jdepsやjdeprscanなどのツールを使います。jdepsはライブラリの依存関係を調べるツールで、deprscanは非推奨なAPIが使われている場合に、それを検出するツールです。
個人的に気になって質問したのは、新バージョンの検証をどれくらいのタイミングで初めていくのがいいかということです。これまではリリースサイクルがゆっくりだったので、JCPが固まって参照実装が出たくらいから検証を始めて、リリース後ある程度こなれてから対応というスパンでも十分でした。新しいリリースサイクルだとあまりのんびりしている時間はなさそうなので、これがどう変わるかということです。
LTSを移行ターゲットにしつつ、その間にリリースされたバージョンを順番に検証していくという形が現実的でしょうか。OpenJDKのリポジトリを追えばリリース前にも検証を進めることは可能だけど、そのサイクルを追うのはさすがにしんどいので、LTS以外は正式リリースを追う形でもいいんじゃないか、というのがきしださんの見解。私も同意です。
また久保田さんは、「まずは Java8 → Java9 を乗り越えること。それさえ乗り越えられれば、その後のバージョン間の差分（新機能とか非互換性とか）はそれほど大きくないので、あまり怖くないはず」とおっしゃっていました。
あと「創るJavaはいつ出るか？」という質問の意図について書こうと思ったけど、長くなったので別の機会にします。
Java Day Tokyo 2018に関するアナウンス
伊藤さんから、Java Day Tokyo 2018関するアナウンスがありました。Java Day Tokyo 2018は5月17日（木）開催。基調講演に、なんとMark Rainhold氏の来日が決まったそうです。これが昨日の一番の驚き。参加登録サイトは近日中に公開予定とのこと。
JJUG CCC 2018 Springに関するアナウンス
JJUGより、 JJUG CCC 2018 Springに関するアナウンスがありました。JJUG CCC 2018は5月26日（土）開催。今月末までCall for Paperを募集中なので、ネタを持っている人は怖がらずに応募して欲しいとのことです。
JJUG CCC 2018 Spring
Eclipse FoundationがJakarta EEプロジェクトに関するサーベイを実施中
去る2017年9月、Oracleはこれまで同社が主導していたJava EEの仕様策定および開発をEclipse Foundationに移行することを発表しました。
それに伴ってEclipse Foundationが新名称を決める投票を実施し、その結果をもって、今後は「Jakarta EE」の名称で開発が行われることが正式に決定しています。
https://mmilinkov.wordpress.com/2018/02/26/and-the-name-is/
現在Eclipse Foundationでは、今後プロジェクトを進めるにあたっての開発者向けのサーベイを実施中です。
Jakarta EE Developer Survey 2018
ごく簡単なアンケートです。期限は2018年3月30日11時59分（太平洋夏時間、日本時間では4月1日3時59分）まで。今後注力していくターゲットを考える上での重要な手掛かりになると思われるので、積極的に参加することをおすすめします。
