読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

Java Day Tokyo 2017 参加報告

http://www.oracle.co.jp/events/javaday/2017/share/img/header.jpg

開催概要

公式サイト

www.oracle.co.jp

受講セッション

  • 基調講演
  • Java 9 and Beyond: Java Renaissance in the Cloud
  • Modular Development with JDK 9
  • Introduction to JShell: Official REPL Tool for Java Platform
  • Java SE 9のすすめ

内容・感想

かなり大雑把に書いてあるので、ちょっと間違てるかも。

去年のJava Day Tokyo内容

suzaku-tec.hatenadiary.jp

基調講演

日本オラクルCEO 杉原氏

IT人材→2030年に60万人不足の見込み。
オラクルとして、一人一人のちからを伸ばす、百人力で解決していくらしい。
問題は、全員そう思っているかどうかだね。
その場に流れされて作業しているようでは、この問題への解決は難しいと思われる。
本人が能力向上を真摯に考えてないと、外部からいくら働きかけても、生産性の向上は低いと思われる。
やはり、能力高い連中がいる中に入っていかなければ、ならないと感じた。

今後のJava EE & SE

オラクルとして、クラウドに本格的に注力している見込み。
その主軸であるJavaには、クラウドをより快適に使えるような機能が追加されていく。

Project Valhara

データの定義の仕方に注力していく印象

Project Panama

Arrays2.0 データの扱いに注力している印象

今後の動向

データに関するインパクトが大きい印象を受けた。 その根底には、関数に必要となる柔軟な型が必要だと感じているのではないかと思われる。

Mazda

今年はMazda
工場ラインにJavaが使われているらしい。
てっきりC, C++とかだと思ったけど。

データ管理部分の基幹系で使っているみたい。

従来

開発環境、アーキテクチャフレームワークを全て共通化している。 基幹系として使っているので、後方互換があるJavaが最適だった

最近

関数を使った柔軟なプログラミング。 大量データ処理。

フレームワークは、肥大化しつつある。そのため、Jigsawには期待している また、大量データを利用しているので、GCの問題に直面している。
今後、データを効率的に活用できる機能に期待している。

jshell

javafxと組み合わせると、統計とかが即時に見れたりしそう。
活用方法が、スクリプトくらいだと思っていたが、他にも用途がありそう。
とくにjavafxと組み合わせると、分析を効率的にできるのではなかろうかと思った。

以前、記事でまとめた。

suzaku-tec.hatenadiary.jp

自転車競技でのJava

現実世界の弱虫ペダル??
計測危機を競技用自転車につけて、勝つために必要な指標をだしたり、勝てるようにするためにトレーニングに活かしているらしい。 個人的に熱かったのは、加速のところ。 ギア比を適切に変えて、適切な負荷をかけていかないと、加速が得られない。 いかにトップスピードに乗れるかが鍵らしいね。

コーチ向けに、データ分析方面には、javafxを使っているらしい。 そして、各サービスは、spring bootで実現しているような資料だった。

今後、勝つために必要な指標の算出、勝つために必要なトレーニング&能力向上の最適化されたトレーニングの発案のためにIoTが使われていく。

そこら辺は、ITナビゲーター2017年版にも書いてあったな。
今後、この流れは主流になりそうな気がする。

suzaku-tec.hatenadiary.jp

Java 9 and Beyond: Java Renaissance in the Cloud

javaで機能追加する優先度

  1. セキュリティ
    クラウドで一番気にされるから必須
  2. 更新しやすさ
    クラウドのメリットである開発速度の向上を目指す
  3. 密度
    安価で安心なものを提供していく。これはクラウドでも要求されるので

Java9

モジュラーと、セキュアでクラウドで更新が簡単なモノを提供するのが、主な内容

jlink

jreを自作できる 小さくつくることができるので、カスタマイズでき、必要なものだけ入れることができる 静的なライブラリになるので、環境にあったものができるようになる。

容量によるライブラリの選別が可能になる。 容量多いから、自前で必要最低限の機能を用意するとかもできるのか。。。
というか、そんなことできるのか?
嘘じゃないか凄く疑いたくなるんだけど、いろんな記事で言及してあるし、嘘じゃないっぽいな。

AOT

静的コンパイラ

翻訳になってるのか? 直訳すぎて、内容が意味不な箇所がいくつかある。 やっぱり覚えないといけないな、英語を

jshell

Javaスクリプトチックなことができるようになった。

G1GC

Java9からデフォルト。

Java9の先

  • ユニフォームモデル
  • メモリの最適化・コンパクト化
  • 相互互換性
  • ライブラリのコンパクト化
  • パフォーマンス

すべてクラウドで結果を残せるようなことを念頭において、機能追加していく印象。
基調講演でも言っていたが、クラウド対応には本腰を入れてやっていくみたい。

データ構造

データは、容量を食いやすい。
もっと最適でコンパクト化されたクラス定義を探している状態。 Cのストラクチャのような、コンパクトなデータ構造を考えている。
データの入れ替えを簡単にできるようする予定。

ネイティブ系に近いことをするのだろうか?
ココらへんの話は、以前チラッと聞いたことがあるきがする。
Java10でメインの機能になりそうな気がする。

Project Panama

ネイティブにデータが存在していることが多い。 そのアクセスにはかなりコストがかかる。 それを楽にすることを主眼に置いている。

Modular Development with JDK 9

全てがモジュール化されるようになった。

アクセス修飾子

public protected なし private

パッケージ間で使うには、publicしかなかった JDK9では、publicが3つの意味を持つようになった。

java.base

javaならどんなパッケージでも使っているはず。

指定が間違っているとコンパイルエラーが発生する。

exports:外部に公開するパッケージ requires:依存するモジュール(パッケージ単位ではない)

java9のモジュール化の違い

module-infoのある/なしだけ
ソースへの影響は、最小限になるように注意したある様子。

jdk

起動・コンパイル時にモジュールの依存関係が非同期でチェックされるため、ClassNotFoundExceptionが実行時に発覚することが少なくなる。

Manavenとか使っていると、よく発生した記憶がある。
解決しようとすると、インフラ担当やフレームワーク担当に事象の説明したり調整が必要だったり、スゲー大変だった。
それがなくなるのだとしたら、早く使いたい。
ただ、解消されるまでに、かなりの山を超えなきゃいけない気がする。
まぁ、いまJavaは使ってないんですけどね!

発生しうる問題

循環参照

だいたいが開発ミスなので、デフォルトNG

モジュールをまたがったパッケージ

そんなのつくっちゃラメェェェ!

モジュールの導入方法

jdkがモジュール化しているので、合わせれば自ずと最適なモジュール化になるはず。

jdkがモジュール化されているからといって、既存のライブラリはモジュール化する必要はない。 モジュール化するには、上から順々に配置場所を確認して行くといい。 そのためには、jdepsを使って、依存を確認して、配置場所を見分ける。

jdeps

Java8から入っているが、依存関係をわかりやすくするツールとして使える。
コイツを使って、依存関係をはっきりさせて、Java9を楽しもう的なことを行っていたと思う。たぶん。。。

外部javaライブラリのモジュール化

automatic modulesで解決出来る。
自動でモジュール化する機構らしい。
ただし、すべてのモジュールに依存するようになるので、なるべく書かないほうがいいと感じた。
使わないで済むなら、そうなるようにすべきだと思う。

モジュール化でやらなければいけないこと

モジュールパスにライブラリのパスを通すだけ

モジュール化

価値もあるけど、注意も必要。
例えば、今まで見えていたクラスが見えなくなって、コンパイルエラーになるなどもある。
特に、作ったライブラリを提供している時は、どうするかをよく考える必要があると思われる。

第三者のライブラリは、automatic moduleで対応できる

Introduction to JShell: Official REPL Tool for Java Platform

手元で数行のコードを各

IDEを汚す

Webサービスでやる セキュリティの観点から、独自ライブラリを上げづらい バージョン対応

他の環境

replツールを使って、即時実行できる環境が提供されている Javaにはなく、徐々に人気が失われている要員になっている

jshell

クラス宣言不要

public, final →無視される なぜなら、jshellで記載されたらどこからでも参照されるので、無視

宣言は、修正して更新することも可能

前方参照

宣言を行う前に参照を記述できる そのため、記述しておいて、あとで宣言することも可能。 入れ子になっていたりする場合は、この仕組で解消している。

強い型付け言語のJavaでこれができるのは、以外

jshellコマンド

すべて"/“で始まる

できること 履歴/スニペット表示/編集/保存

Startup

jshell起動時に実行される カスタマイズ可能。 デフォルトは、jdkの大名パッケージ 設定は、/setコマンドで実行可能

設定した内容は、永続化されない。 永続化するには、/setで永続化オプション(-relate)を付ける

JShell API

jline→jshell tool→jshell coreの順に伝わる 入力が終わったら、コンパイルされ、クラスファイルができて実行されるらしい。 デモ見た限りだと、そこまで遅い印象はない。

  • jshell
    入力の受け口
    受けっと値を評価して、ShippetEventoに渡す

  • SnippetEvent
    評価さえたコードを受け取る

  • SourceCodeAnalysis
    入力が終わったのか判定する

  • xxxsnippet

debugコマンド

内部の挙動のトレースができる

Q&A

jshell→スクリプトファイルにできる

jshell内でスレッド実行 → 別JVMで動いているので、jshellには影響なし

jshellの用途 → 今後模索

同一JVM内で実行しない理由は? → jshellに影響をあたえるため、別JVMで実行している

thisは使えるか? → トップレベルでは無理

いつも使うライブラリをデフォルトで読み込めないか? → コマンドで頑張ればできるから、頑張れ

製品として組み込みで使えるか? → 難しい。やればできるけど、おススメはしない。 JVMがデフォルトで2つ立ち上がるので、パフォーマンスが悪い

importしたものをあとで外す → コマンドで外せる

jshellのステップ実行 → 現段階では無理。今後できるようになるかも

Java SE 9のすすめ

compatibility

language & library

アンスコだけの変数 → 使えなくなる  そもそも使っている人は少ないから、たぶん大丈夫だと思う  Java8使ってたころは、警告等は見かけなかった。

アンダースコア始まりは、問題なく使えるので、大丈夫

いろんなメソッドが使えなくなっている。(使用頻度少なそうなやつ) ほぼJigsaw関連。 deplicateの奴があり、いつ使えなくなるのかわからないので、注意して開発する必要がある。

vm & tools

Java Plug-in Applet サポートが無くなる

Windows x86 Client VM → なくなった Javaでクライアントサイドのやつを使ってやる人は、要注意

JavaDB → 消えた

operation & management

Visual VM → 死んだ hprof, jhat → なくなった

運用面は、結構被害が大きそう

JRE構造
  • jre-9
    • bin
    • conf
    • lib

rt.jar, tools.jar, lib/ext, -Xbootclasspathは、天に召された。

G1GCがデフォルトになる。メモリが少ない場合はParallel GC
CMSは、deprecatedになった。
いつなくなるのか不明のため、早めに移行計画をする。

brand new

reactive streams

非同期処理のためのインタフェース インタフェースだけの提供。実装は今後。

JEP incubator modules

キュウべぇのことではない。
non-final applicationsのこと。
つまり、最終版ではないAPIをいれようぜってことらしい。
なくなるのか、どうなるのか分からないので、使う場合は要注意。

試験的な位置づけらしい。
研究職向けなのかな?
意図までは、セッションでは分からなかった。

update

milling project coin

ちょっとした変更をいれようぜって感じだと受け取った。
project-coinで入ったものを、もう少し使いやすくするらしい。

try-with-resources

readerの変数定義をtryでしなければいけないので、面倒くさい finalにすれば指定可能にする 実質finalの概念も適用される

ダイヤモンド演算子

匿名クラスでは、ダイヤモンド演算子が使えなかった。
それが解消された。 ワイルドカード(?)など、型推定できない場合は、エラーになることがある。

匿名クラスは、ラムダが出たので、使う機会が少ないかもしれない

streams

ラムダでfor分みたいなことができるようになった。 Collectors.flatMapping, Collectors.filteringが追加。

Optional

  • stream()
  • ifpresentorelse
  • or

Collection

of()

作られたものはイミュータブルになる。 今まで定数としてlistとして使いたい場合、かなり面倒くさいことをしてたものが、かなり楽になる。

いわゆる不変コレクションってヤツが作れる。
下記の記事で一回まとめた。

suzaku-tec.hatenadiary.jp

String

char → byte に変わった 文字列が占める容量の割合が大きいために対応されたみたい。
日本語は、以前と同様にutf-16になる。

+連結

StringBuilder → InvokeDynamic 必要なときに容量確保されるので、最適化がされるはず。

deprecated

何時からってのが使える様になる deprecatedのものは、必ず確認or消す努力をしないと、アップデートできないって事象に陥る可能性がある。

全体通しての感想

疲れた。
朝の満員電車で、体力をゴソッと持って行かれたのが辛い。
年のせいか、体力が持たない。
まだ20代のハズだが。。。
ポケモンGoで毎日チャリに乗って30分くらい駆け回っているけど、そんなんじゃ体力強化できないってことがわかった。

Java9は、Jigsawの変更内容が追いきれていないって感じがした。
あと、Jigsawばっかりに目が行って、他の変更が頭に全然はいってないってことがよくわかった。
特にStringは、char→byteになったのは結構衝撃的だった。

jshellは、やり方知っていたけど、全体を俯瞰しての作りを知れたのは大きい。
ソフトウェアに組み込むのは難しい印象を受けた。
どっちかというと、開発を補助するツールって印象。
JavaFXとの親和性が高い印象を受けた。
JavaFXを学ぶことの有用性があった気がする。

今後するべきタスク

  • Jigsawのサンプル確認
  • Stringの変更点確認 char→byte
  • jshellとJavaFXの連携