Javaが最強JVM言語になる日はくるのか / Will Java become strongest JVM language

2020/10/4にオンラインで行われたJ Lang Fest Kansai Online #1での登壇資料です https://kansai-jvm-langs-fest.connpass.com/event/188249/

Transcript

1. Javaが最強JVM言語に なる日はくるのか LINE Fukuoka きしだ なおき 2020/10/4 J Lang Fest Kansai Online #1 Microsoft Flight Simulator 2020
2. 自己紹介 • きしだ なおき(@kis) • LINE Fukuoka • MSフライトシミュレータで墜落がうまくなった • オンライン登壇での待機中にキッチンを片付け たくなる
3. この発表で「Java」はJava言語を示します
4. Javaはいまでも 最強JVM言語です 終 制作・著作 ⓀⒾⓈ Microsoft Flight Simulator 2020
5. Java Bean 関数型 セミコロン省略 equals Stream public static void main ラッパークラス 非同期処理 null メソッド定義 パターンマッチング
6. Java Bean • コンストラクタ • setter / getter • toString / equals / hashCode • IDEでの自動生成やlombokでの暗黙の生成ができるとはいえ 面倒
7. Java Beanへの対応 • Records(JEP 384, preview) • イミュータブルなデータ運搬型を定義できる
8. Recordsの欠点 • ミュータブルにはできない • setter / getterは定義されない • 属性と同じ名前のメソッドが定義される • 既存のフレームワークがそのまま使えない
9. パターンマッチ • パターンマッチかっこいい
10. パターンマッチへの対応 • instanceofで型パターンマッチに対応(JEP 375, preview 2) • switch式(JEP 361, standard) • switchでのパターンマッチ(JEP Draft) • Recordの分解(未JEP) • 仕様決め難しそう
11. null • nullは悪 • Optionalめんどい
12. nullへの対応 • Optionalのパターンマッチへの対応(構想あり) • unapply相当の仕組みで対応する • 時間がかかりそう
13. 文字列定義 • 複数行の文字列を定義したい • 変数を埋め込みたい
14. 文字列定義への対応 • Text Blocks(JEP 378, standard) • ダブルクオート3つで複数行文字列の定義 • 変数補完(インターポレーション)はない • formattedというメソッドが導入されたので代替 • "message is %s".formatted("hello")
15. 非同期処理 • 通信中に別の処理をしたい • Kotlinにはコルーチンがある • Rxは人類には早すぎた
16. 非同期処理への対応 • Project Loom • 仮想スレッドのJVMへの導入 • OS管理ではなくJVMで管理するスレッド(グリーンスレッド) • OSリソースを食わないので軽量 • バイトコードレベルで対処を行う • 言語仕様への変更不要 • synchronizedまわりに変更あるかも？ • 他の言語にも恩恵あり • 着実に開発進んでる模様
17. ラッパークラス • intやbooleanなど基本型に対応するラッパークラスが必要 • 変換自体は自動で行われるので意識することは少なくなった • Genericsで基本型が使えない • IntStreamやOptinalInt、IntFuncitonなど基本型用のクラスや インタフェースが必要
18. ラッパークラスへの対応 • Project Valhallaで進行中 • List<int>が書ける • バイトコードを拡張 • 新しいバイトコード命令の追加 • つまり大工事
19. Project Valhallaの問題点 • あまり順調ではなさそう・・・ • 基本型の値に対してメソッドを呼び出すことはできなそう • 123.times(System.out::println)のような書き方はできない
20. メソッド定義の簡素化 • 式を返すだけなのにいろいろ書かないといけない • String myMessage(String m) { return "message is %s".formatter(m); }
21. メソッド定義の簡素化への対応 • Concise Method Bodies(JEP draft) • String myMessage(String m) = "message is %s".formatted(m); • 処理が単一の式であればreturnが不要になる
22. ローカル関数 • メソッドの中でメソッドを定義したい • ラムダを使うのは美しくない • 匿名クラスを使うのはハッキー • var m = new Object() { double area(double r) { return r * r * PI; } }; println(m.area(5));
23. ローカル関数への対応 • Gitにそれっぽいブランチがある
24. 関数の後置(中置) • 関数をうしろに書きたい • Kotlinのletとか • String.formatに対するformattedのようなものを普通に 使いたい
25. 関数の後置への対応 • String.transform • 他のクラスにも拡張するかも？
26. 拡張メソッド • Stringとか拡張したい
27. 拡張メソッドへの対応 • 計画の気配なし • 理論的には可能
28. メインメソッド • public static void mainってややこしい • クラスが必要になるのもわかりにくい • 使い捨て処理を書くのが面倒 • 初心者の入門を阻害
29. メインメソッドへの対応 • 計画の気配なし • 理論的には可能 • javacなしでjavaコマンドだけでの実行は可能 • Launch Single-File Source-Code Programs(JEP 330)
30. equals • 同値性の検証にメソッド呼び出しが必要 • 間違いがち • めんどう
31. equalsへの対応 • 予定なし • 互換性考えると無理
32. Stream • stream()ってつけるの面倒 • Listを出力したいときのcollect(Collectors.toList())が面倒 • 直接toListってやりたい • toArrayはある
33. Streamへの対応 • StreamをCollectionフレームワークに依存させたくないという Brian Goetzの強い意志があるので無理
34. 関数型 • ラムダ式によってリテラルとしては記述できるようになった • 型としてはインタフェースを使う必要がある • 必要な型に対応するインタフェースを覚えるのは大変 • Function / Supplier / Comsumer • IntFunction / ByFunction・・・ • 例外に対応しようとすると別に定義が必要 • 仕様がややこしい
35. 関数型への対応 • 無理そう
36. セミコロン省略 • 流行りはセミコロンの省略 • Javaでセミコロンを書かずに処理を書くのは変態
37. セミコロン省略への対応 • 過去のコードがコンパイルできるよう仕様変更するのは無理 • セミコロンと和解せよ
38. その他 • ifは式にならないの？ • 条件演算子を使おう • 戻り値の型推論は？ • 構文上、結局varって書くことになるのであまり意味がなさそう
39. ここまでのまとめ 機能 状況 Java Bean Recordで対応 フレームワークの対応が必要 パターンマッチ 実装中 deconstructionは時間かかりそう null Optionalへのパターンマッチ まだ時間がかかる 文字列定義 Text Blocks 変数補完は入らなそう 非同期処理 Project Loom ラッパークラス Project Valhalla 先は長そう メソッド定義の簡素化 JEP draft ローカルメソッド Gitにブランチあり 関数の後置 String.translate 拡張メソッド 理論的には可能 計画なし メインメソッド 理論的には可能 計画なし equals 無理 Stream 無理 関数型 無理 セミコロン省略 無理
40. JavaがJVM最強言語に なることはありません 終 制作・著作 ⓀⒾⓈ Microsoft Flight Simulator 2020
41. まとめ • Javaの改善は続いている • 既存構文との整合性を考えると最強になりえない • Javaで言語機能が対応するとJVMに最適化機構が入る • 他の言語でも性能が改善する
42. JVMが最強実行環境で あればそれでいいのだ 終 制作・著作 ⓀⒾⓈ Microsoft Flight Simulator 2020