ほぼ中身がないですが、すごく重大ニュースなので、日本語で検索したときに引っかかりやすい的な理由により、雑に書いておくだけのエントリ。
以前JDKのversionが上がったのは、主にJDK 8でinterfaceのdefault実装が持てるようになり、Scalaのtraitでもそれを利用するようにしたいよね、という経緯により決定された Scala 2.12からです。Scala 2.12.0のリリースは2016年10〜11月頃らしいので、実に8〜9年ぶりです。 (他にはSAM type関連でも8以上になってた方がいい、などもあった気はするが)
- https://github.com/scala/scala/releases/tag/v2.12.0
- https://repo1.maven.org/maven2/org/scala-lang/scala-library/2.12.0/
つまり、例えばScala 2.10や2.11はJava 7でも動いていたわけですが、Scala 2.12以降はJava 7では動かなくて8以上が必須になったわけです。 それと同じようなことが、かなりひさしぶりに発生することが決定されました。
以下の記事
https://www.scala-lang.org/blog/next-scala-lts.html
に上げたくなった理由は書いてありますが、簡単に説明しておくと、一番の理由は以下
のlazy valの実装問題です。
これ書いてる2025年3月の時点のScala 3は、lazy valに sun.misc.Unsafe を使ってしまっています。
が、それはやめたい
↓
やめるには VarHandle 使うのが良さそう
↓
VarHandle はJDK 9以降なので、(よほど工夫しない限り)普通に実装したらJDK 8のサポートは打ち切るしかない
↓
まぁもう打ち切りでいいでしょ！
↓
ついでに最低は11ではなくて、この際17でいいんじゃないですかね？？？(ここの詳細の決定理由よく知らない)
という流れのはずです。 あくまで次のScala 3なので、今までのScala 3.xやScala 3.3.x系のLTSやScala 2系では今のところJDK 8サポートを続ける可能性がかなり高いですが、 いよいよ8も11も終わりか〜、と思うと、感慨深いですね。
最新のScala 3がJDK 17必須になったからといって、各種ライブラリは、少なくとも次のLTS(詳細決まってないが3.9なの？)、が出るまでは、おそらくScala 3.3.x系のLTSでbuildするライブラリが多数で、すぐに全部がJDK 8や11を切り捨てないとは思いますが、これは実際に今後の動向を見てみないとわかりません。
