開催概要
公式サイト
受講セッション
- 基調講演
- 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内容
基調講演
日本オラクル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と組み合わせると、分析を効率的にできるのではなかろうかと思った。
以前、記事でまとめた。
自転車競技でのJava
現実世界の弱虫ペダル？？
計測危機を競技用自転車につけて、勝つために必要な指標をだしたり、勝てるようにするためにトレーニングに活かしているらしい。
個人的に熱かったのは、加速のところ。
ギア比を適切に変えて、適切な負荷をかけていかないと、加速が得られない。
いかにトップスピードに乗れるかが鍵らしいね。
コーチ向けに、データ分析方面には、javafxを使っているらしい。 そして、各サービスは、spring bootで実現しているような資料だった。
今後、勝つために必要な指標の算出、勝つために必要なトレーニング＆能力向上の最適化されたトレーニングの発案のためにIoTが使われていく。
そこら辺は、ＩＴナビゲーター２０１７年版にも書いてあったな。
今後、この流れは主流になりそうな気がする。
Java 9 and Beyond: Java Renaissance in the Cloud
javaで機能追加する優先度
Java9
モジュラーと、セキュアでクラウドで更新が簡単なモノを提供するのが、主な内容
jlink
jreを自作できる 小さくつくることができるので、カスタマイズでき、必要なものだけ入れることができる 静的なライブラリになるので、環境にあったものができるようになる。
容量によるライブラリの選別が可能になる。
容量多いから、自前で必要最低限の機能を用意するとかもできるのか。。。
というか、そんなことできるのか？
嘘じゃないか凄く疑いたくなるんだけど、いろんな記事で言及してあるし、嘘じゃないっぽいな。
AOT
静的コンパイラ
翻訳になってるのか？ 直訳すぎて、内容が意味不な箇所がいくつかある。 やっぱり覚えないといけないな、英語を
jshell
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がデフォルトで２つ立ち上がるので、パフォーマンスが悪い
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として使いたい場合、かなり面倒くさいことをしてたものが、かなり楽になる。
いわゆる不変コレクションってヤツが作れる。
下記の記事で一回まとめた。
String
char → byte に変わった
文字列が占める容量の割合が大きいために対応されたみたい。
日本語は、以前と同様にutf-16になる。
＋連結
StringBuilder → InvokeDynamic 必要なときに容量確保されるので、最適化がされるはず。
deprecated
何時からってのが使える様になる deprecatedのものは、必ず確認or消す努力をしないと、アップデートできないって事象に陥る可能性がある。
全体通しての感想
疲れた。
朝の満員電車で、体力をゴソッと持って行かれたのが辛い。
年のせいか、体力が持たない。
まだ２０代のハズだが。。。
ポケモンGoで毎日チャリに乗って３０分くらい駆け回っているけど、そんなんじゃ体力強化できないってことがわかった。
Java9は、Jigsawの変更内容が追いきれていないって感じがした。
あと、Jigsawばっかりに目が行って、他の変更が頭に全然はいってないってことがよくわかった。
特にStringは、char→byteになったのは結構衝撃的だった。
jshellは、やり方知っていたけど、全体を俯瞰しての作りを知れたのは大きい。
ソフトウェアに組み込むのは難しい印象を受けた。
どっちかというと、開発を補助するツールって印象。
JavaFXとの親和性が高い印象を受けた。
JavaFXを学ぶことの有用性があった気がする。
今後するべきタスク
- Jigsawのサンプル確認
- Stringの変更点確認 char→byte
- jshellとJavaFXの連携
