JavaOne 2017 レポート 10/2 Day-2 キーノート&技術セッション
さて、Day-2からがいよいよ本番です。
これ以降、技術的セッションとか真面目に掘り下げると色々破綻するので(理解できてないとか時間が足りないとか)、ざっくり駆け足のレポートでお茶を濁していきます。
なお、当日の見聞きした(気がしている)そのままであり全部裏を取ってる訳ではないとか、そもそも発表自体が「現状ではこの予定です」みたいなものがあったり(Safe Harbor Statement)なので、これ以降の技術内容については不正確・誤り等がある可能性がありますが、その辺はご承知おきください。
IntelliJ IDEA Tips and Tricks
ひたすら、IntelliJ IDEAのTIPSを紹介していくだけのセッション。 とりあえず、同じ時間帯で他にめぼしいのがなかったので、耳慣らしを兼ねて。
結構普通に使ってる機能が多かったのですが、↓あたりは使いこなしてないので、使ってみようかなと思います。
(以下、メモから書き起こしただけなので名称やキーバインドは間違ってるかも)
- Search Everywhere (Shiftx2)
- Recent files (Cmd+E)
- タブ表示を無しにしても開いているファイルを簡単に行き来できる
- Productifity Guide
- テンプレート系
- psvm ->
public static void main
の略でメインメソッドを生成する - toar -> コレクションから配列に変換する(?)
- Template list (Cmd+J)
- どんなテンプレートがあるか覚えてなくてもリストから選べばよい
- psvm ->
- Extract Variables (Option+Cmd+V)
- fキーで抽出定義した変数宣言に
final
をつけるかどうかをトグルできる
- fキーで抽出定義した変数宣言に
- Next Error (F2)
- 警告やエラーの下線部分にジャンプしていく
- 補完時に
h.f
おようにドット区切りで書いてから補完するとhoge.foo()
のようにメソッドまで一気に補完できる - コンテキストにあった補完 (Shift+Cmdx2)
- Navigate Delcaration (Cmd+B)
- Stringリテラル内の文字列に対して、XMLやSQLなどの別のフォーマットを指定できる
- Abbreviationを自分で定義すると便利
- (Templateとの違いがよくわかってない)
- Stream Debugger
Improving Your Groovy Kung-Fu
Groovy in Actionの著者であるDierk Konig氏のGroovyのTIPS的セッション。 スライドなしで、Groovy Consoleやテキストエディタを使って、ライブ的に進める流れ。
- sdkmanのサブセットっぽい、senvというオレオレスクリプトをネタに、GroovyでのスクリプトコーディングのTipsを説明
- IPアドレスを取得するワンライナで、JavaのAPIがそのまま使えるよ、みたいな話
- GParsのDataflowsを使うと、parallelで明示的に並列処理&JOINするより並行処理的知識を隠蔽できる
- GroovyFXでGUIがコンパクトなスクリプトで書ける
みたいな、(期待はしていませんが)ほぼ既知の内容でした。
GParsのDataflowsは名前は知っているものの実際に使ったことがなかったので、ちょっと気になりました。
import static groovyx.gpars.dataflow.Dataflow.task def df = new Dataflows() task { df.z = df.x + df.y } task { df.x = 10 } task { df.y = 5 } println "Result: ${df.z}"
こんな感じのコードが書けます。 非同期処理においてそれぞれの値が確定する時間差などを気にせずに、宣言的に記述できるのが良さそう。
細かいですが、逆の意味で気になったのは、次のような例外catch部分。
try { //... } catch (all) { println "Error: $all" }
Groovyではcatch節でも型を省略できるんですが、その場合Exception
型を指定したときと同じになります。
慣習的に変数名としてe
あたりが無難ですが、all
というのはなぁ。
「型指定してないし、Exception
型以下ごっそりキャッチしまっせ」的な気持ちかもしれないけど、あまり同意しかねる感じ。
ちょうどつい先日、StackOverflowの回答のサンプルコードで見かけて「変なの」と思ってたので、引っかかりました。
Java Keynote
午後からはMoscone Northの地下会場で、基調講演を聞きました。 内容は各種メディア系ですでに素晴らしい感じでまとめられてるので割愛1。
What's New in Gradle 4.0
Gradle 4.0(一部3.xも含む)で追加された新機能などをざっと紹介していくセッション。
- パフォーマンス向上系
- New Tools
- Java Library Plugin
- プロダクトが「アプリケーション」なのか「ライブラリ」なのかで依存性のあり方が違うはずである
- 今までの
cmpile
とruntime
というコンフィギュレーションの分け方では非効率 - 新しく
api
とimplementation
というコンフィギュレーション形式にした。- ライブラリとして使う部にも意識させたい依存性は
api
として定義する - 単なる内部実装にすぎなくて、使う側に意識させたくない/させる必要がない場合は、
implementation
として定義する
- ライブラリとして使う部にも意識させたい依存性は
- Java以外のNative系のビルド
- Parallel Compile/Linkingがデフォルトサポート
- Composite Building
- 複数のPJ間依存関係において、いい感じにビルドを連携する(?)
- Java Library Plugin
- User Experience
Module Development with JDK 9
3部構成で、JDK 9でモジュールを活用した開発をするために必要な情報を整理したセッション。
- 第1部 「モジュールは再利用のためのパッケージのセットである」
- 以下のような流れで変遷してる
- Programs are Classes
- Programs are Packages
- Programs are Modules ←イマココ
- Java 8までの
public
は、Java 9で3つに細分化された- public for everyone (モジュール内外を問わず、誰でもアクセスできる。Java 8のpublic相当)
- public to only friend (モジュール内は誰でもOK、モジュール外からは
to
で指定したモジュールからだけアクセスできる) - public only within a module (同一モジュール内の全てのクラスに対してはpublicだけど、モジュール外からはアクセスできない)
- JARファイル単位=再利用単位
- Fat Jarのように、JARファイルの中に依存先のJARファイルを同梱している訳ではない
- 複数のモジュール(JAR)で、同じパッケージを作ることはできない
- それぞれのモジュール内で、「だれが開発したか(どのモジュールに含まれているか)」がわかるようなパッケージ名を使う必要がある
- (他のJava 9対応HowTo系のセッションをみると、この制約に対する修正について割と手間がかかりそうな雰囲気でした)
- それぞれのモジュール内で、「だれが開発したか(どのモジュールに含まれているか)」がわかるようなパッケージ名を使う必要がある
- 以下のような流れで変遷してる
- 第2部 モジュールへのマイグレーション
- jdepsツールを使うと便利 (java 8から同梱済み)
- 既存プログラムの依存性分析ができる
- Automatic Modules
- 命名規約に基づいて、モジュール化未対応のライブラリもモジュールとして扱える
- モジュール依存関係に登場する全てを
requires
に指定したような依存関係を持つとみなされる
- jdepsツールを使うと便利 (java 8から同梱済み)
- 第3部 Modular JDK
本日のディナー
JCP Partyでウェーーイとビールや軽食をいただいた後、若干怪しい道を通ってベトナム料理店へ。 だいぶお腹いっぱいな中の2軒目でしたが安くて美味しかったです。