2018年6月21日

Javaのリリースサイクルが変わることによるScalaへの影響

たまにこういう話が出てくるけれど、みんな漠然とした不安で話をしている感じがするので、 (もちろんこれもまた予想でしかないですが)、多少は自分はScala事情に詳しいと思うので、ある程度の予想や実情をtweetしたので、せっかくなのでまとめておきました
4
あれふ@ギーくらやま(入居者募集中!) @40balmung

scalaやgroovyなどJVM言語はopenJDKをベースにすると思うんだけど、半年ごとに対応するのかな #jjug

2018-06-20 20:10:12
mryo0826 @mryo0826

素のJavaじゃなくてScalaとかJVMつかった言語だと今後のJDKのリリーススケジュールにどういう対応するかなんだよなぁ。それよりOpenJDKの今後の方針がわからないといろいろと怖いけど…。 #jjug

2018-06-20 20:56:33
shinyafox@bitter_fox @shinyafox

Q「Scalaなど、Javaのエコシステムを利用する言語は今回のリリースサイクルの変更でどのような影響を受けると思われるでしょうか?」 結構大変な気がします。どのバージョンのJavaをサポートするかとか、そういう選択も迫られるし、新しいJavaをサポートするためにリソースが取られたりしそう #jjug

2018-06-20 21:18:14
Kenji Yoshida @xuwei_k

twitter.com/shinyafox/stat… 以前からこういうtweet見かけるが、半年ごとに大幅に互換壊れるversionが毎回登場するならともかく、(少なくともJava 9から11あたりでは)ほぼ互換ありつつ新機能追加みたいな感じだと思うので、そうすると基本的にはあまり何もせずに動く場合も多々あるので、なんかこう #jjug

2018-06-20 21:38:12
Kenji Yoshida @xuwei_k

もちろん、新しいJVMの機能使った最適化などやろうとすると、古いversionのJava捨てる判断迫られるし、その最適化がどの程度難しくてリソース必要か?などはあるが、ひとまずそのまま動かすという意味では #jjug

2018-06-20 21:38:13
Kenji Yoshida @xuwei_k

JVMの新機能を使うことによっての古いJavaを切り捨てる判断が必要になる、あたりの問題は、普通のJavaライブラリ作ってても発生しうるので、それらで発生する問題とJVM上のJava以外の言語でも、ある意味同じというか #jjug

2018-06-20 21:38:13
shinyafox@bitter_fox @shinyafox

@xuwei_k 個人的にはJVM言語を使った開発と言うよりかは、JVM言語を作る側の想定ですね。となると最新のJavaベースでガリガリにその機能を使いたい勢と古めのJavaもサポートしたい勢とのコンセンサス取りが今まで以上に必要になると思うのでそのリソースが取られそうなのと

2018-06-20 23:44:26
shinyafox@bitter_fox @shinyafox

@xuwei_k つねに最新のJavaベースで最適化するなら本来の言語開発でない部分に半年ごとにリリースが必要になるので辛そうというイメージです。JVM言語以外のライブラリにも同じ課題があるというのには同意です。

2018-06-20 23:45:40
Kenji Yoshida @xuwei_k

@shinyafox (ある程度は自分の予想でしかないですが)、Scalaの場合もともと、ずっと1、2年に1度程度のペースでリリースしているので、よほど革新的な魅力的な機能がJVMに搭載されたとしても、どう考えても半年に1回のリリースなんてやらないと思うので、それはかなりの確率で杞憂だと思うんですよね

2018-06-21 00:05:09
Kenji Yoshida @xuwei_k

@shinyafox あと、コンセンサス取ることそのものの手間というかリソースは、たいしたことないというか。 多少コミュニティの意見聞くことはあっても、ある意味最終的にはScala作ってる中の人のトップダウンで決まるし

2018-06-21 00:06:04
shinyafox@bitter_fox @shinyafox

@xuwei_k なるほどーScalaもそういうスピード感なんですねもっと早いイメージありました。コンセンサスはOpenJDKのMLとか見てるの技術でない部分で議論してたりしてウザいなーと思ってたりしたので、、、

2018-06-21 00:10:46
Kenji Yoshida @xuwei_k

@shinyafox なるほど…。最近の例だと、Java 8のリリースが2014年前半で、8の機能を使うようになった(Java 7を切り捨てた)Scala 2.12の最初のリリースが2016年後半で、2年半以上あいたんですけど、その程度間があいても、自分の実感としてはそこまで大きな不満は聞かなかった気がしています

2018-06-21 00:15:20
shinyafox@bitter_fox @shinyafox

@xuwei_k 意外とアグレッシブな開発者そんなに居ないんですね!そういう感じだと割と今まで通りみたいな感じで開発されていきそうですねーメジャーなLTSベースでサポート切っていくとか。

2018-06-21 00:19:58
Kenji Yoshida @xuwei_k

@shinyafox あと、これはこれで開発側は確かに大変になるんですが、場合によっては、デフォルトではJava 8を維持しつつ 「-target:jvm-9のオプション明示した場合のみ新しい機能使って最適化したバイトコード生成する」 という機能をマイナーアップデートで追加する。 みたいなことはあり得るので、

2018-06-21 00:25:28
Kenji Yoshida @xuwei_k

@shinyafox Javaのリリースサイクルがはやくなったことに引きずられて、Scalaのメジャーアップデートのサイクルがはやくなるとは限らない、などもありますね

2018-06-21 00:25:45
Kenji Yoshida @xuwei_k

twitter.com/xuwei_k/status… もちろん不満がゼロではなかったとは思うが、2.12でJava 8対応するというロードマップは以前から示してあったし、どちらにしろ出たばかりのJava 8すぐ使う人もそこまで多数派ではないとか、不満あるとすれば2.12自体のリリースが当初の予定より遅れたとか、そういう(?)

2018-06-21 00:32:51
Kenji Yoshida @xuwei_k

あとはScalaもそれなりに広まってきたとはいえJava自体のユーザー数と比べれば、まだかなり少数派なので、既に使ってる人は、もともと一定以上Scalaに魅力を感じてる人なので、2年ちょっと遅れた程度でScalaやめたいと思うほどにしかメリット感じてなかったなら最初からScala使ってない(?)とかだろうか

2018-06-21 00:36:26
Kenji Yoshida @xuwei_k

このあたり、そろそろ将来のScalaとJavaのversionの対応のロードマップをScala公式で示して欲しい気がしなくもないけど、たぶん特に今は予定がないというか、Java 8を切り捨てて9以降の機能で積極的に必須で使いたい機能なんでまだほぼ出てきてない、くらいが実情なのかなぁ🤔

2018-06-21 00:41:12
Kenji Yoshida @xuwei_k

twitter.com/xuwei_k/status… これの例となるかもしれないやつはこれ github.com/scala/scala/pu… というか、Java 6以上サポートの Scala 2.11 にも jvm-1.7 や jvm-1.8 のオプションある(マイナーアップデートで追加された前例がある)

2018-06-21 00:49:52
Kenji Yoshida @xuwei_k

project valhallaあたりで、もし大幅にclassファイルの仕様も拡張されるなら、Scalaもそれを使った方が明らかに効率良い、となって、それが入る前のJavaを切り捨てる未来が中長期的には来るかもしれない(?) (valhallaが具体的にどう実装される予定なのかよく理解してない状態の多少適当な発言)

2018-06-21 01:07:29
Kota Mizushima (on a diet) @kmizu

togetter.com/li/1239273 の話、個人的には別にScalaに限らずKotlinやClojureなどの他のいわゆるJVM言語でも大差なかろうと思ってて、なんでかというと、クラスファイルフォーマットに非互換な変更が入ったり、新命令が入ったりしない限りは、大きな修正入れなくても原理的に動くはずなんですよ。

2018-06-21 18:09:07
Kota Mizushima (on a diet) @kmizu

そうすると、あとは、新しいJVM(Java言語ではない)でサポートされる機能を取り込むことでどれくらいJVM言語のユーザが嬉しいかという話になるわけですが、少なくとも積極的にサポートして嬉しいことが明らかな機能は、まだないなあという印象。

2018-06-21 18:11:36
Kota Mizushima (on a diet) @kmizu

以前は、Project Valhallaが唯一それに該当するのではと思っていたのですけど、 openjdk.java.net/jeps/169 で "This work is not intended to change the Java Language Specification or JVM bytecode instruction set." と言ってるので、コンパイラ側で対応すべきこことは少なそう。

2018-06-21 18:13:21
Kota Mizushima (on a diet) @kmizu

補足すると、instruction setを変えないということは、当然、ユーザ定義の値型のローカル変数やフィールドをロードしたりストアしたり等する命令も追加されないはずで、それならコンパイラの方はやることあんまり多くなさそう、という予想です。

2018-06-21 18:15:11
Kota Mizushima (on a diet) @kmizu

現状の提案としては、lockPermanently という(おそらく)メソッドを定義することで、オブジェクトのaliasingに関するヒントを与えるという方向性のようなので、この方向でやるなら、今まで通りのコードを吐いてれば、今まで通りの性能が出るんじゃないかなあという気がします。

2018-06-21 18:18:04
残りを読む(5)

コメント

Kota Mizushima (on a diet) @kmizu 2018年6月21日
JVM言語というかScalaへの影響は過大に見積もられ過ぎてるかなと思ってなんかコメント書こうかなと思っていたところ、 @xuwei_k さんが割と的確にScala事情を踏まえてツッコミしてくれて良かった感ある。
0