From 295dbff8f2b78dba99316a66de68e6400a06e613 Mon Sep 17 00:00:00 2001 From: Tomasz Godzik Date: Tue, 21 Jan 2025 16:55:14 +0100 Subject: [PATCH 1/9] docs: Create blog about the next Scala LTS --- _posts/2025-02-01-next-scala-lts.md | 82 +++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 _posts/2025-02-01-next-scala-lts.md diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md new file mode 100644 index 000000000..6eec525cc --- /dev/null +++ b/_posts/2025-02-01-next-scala-lts.md @@ -0,0 +1,82 @@ +--- +category: announcement +permalink: /news/next-scala-lts.html +title: "Next Scala 3 LTS version" +by: Tomasz Godzik +--- + +**TLDR;** + +sun.misc.Unsafe, re-used in lazy val implementation, will be removed in a future +JDK one of the Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 +support + +## Intro + +For the compiler’s second LTS version, the Scala 3 compiler team will be +dropping support for JDK 8 and is considering which later JDK to use. + +## Reasons for the change + +One of the main reasons is that recent [JEP 471](https://openjdk.org/jeps/471) +stated that the memory-access methods in sun.misc.Unsafe are scheduled for +removal in a future release. Currently, Scala 3 uses sun.misc.Unsafe in its +implementation of lazy values. This was needed due to compatibility with JDK 8. +In order to support later versions of JDK we will need to drop usage of Unsafe, +which is being investigated under +[this issue](https://github.com/scala/scala3/issues/9013). It also started to +dawn on the compiler team that we might consider stopping to support JDK 8 +altogether in a future release of Scala 3. + +## Advantages + +Switching to a newer version of the JDK would allow both the compiler and the +Scala ecosystem to start using new features brought in by JDK 9+. This might +include a number of JEPs, which will be investigated by the team the coming +year. To check the current status take a look at the issues marked with the +[JEP label](https://github.com/scala/scala3/issues?q=is%3Aissue+is%3Aopen+label%3Acompat%3Ajava%3Ajep). + +Another advantage would be reducing the maintenance burden on tooling and +library authors that currently have to take into account a large number of +different versions to test and make sure that their code is performant on all of +them. + +If we take a look at the timeline we'll see that JDK 8 was first published on +18th March 2014, which is already over 10 years ago. Technology and especially +JDKs have advanced greatly through that period and in order to stay competitive +using those advancements is a must. A lot of the existing distributions are +already stopping or will soon stop updating JDK 8 with security and other fixes, +which might directly impact issues within your business applications. + +Some larger projects within JVM and Scala ecosystems have already dropped JDK 8 +support. And while it's always possible to not update your libraries and Scala +version, which will avoid having to switch to a newer JDK, it's highly +discouraged as it will make you vulnerable to potential security risks. + +## Plan for making the switch + +The current plan is to drop support of JDK 8 in one of the future minor releases +of Scala 3 and in the next LTS. The JDK will be either 11 or 17 depending on the +community feedback and our investigations. The current estimate for the next LTS +is Q4 2025. + +One of the major challenges here will be making sure that we are still able to +use libraries compiled with earlier JDK 8 compatible Scala 3 versions in the +versions with a new implementation of lazy values, which is not reliant on +sun.misc.Unsafe. + +## How does it affect me? + +If you are using Scala 3 on JDK 8 do let us know! However the current line of +LTS under 3.3.x will be supported for at least another year after the release of +the next LTS version, which should give you plenty of time to migrate. + +If at any point it turns out it's not possible for you to switch, be sure to +send us your feedback. + +## Summary + +You can track the current work related to lazy values under +[this issue](https://github.com/scala/scala3/issues/9013) and discuss the topic +under soon to be posted thread on the +[Scala contributors forum](https://contributors.scala-lang.org/) From 995f8c660e5ab97d2395f4f7fc0317179a15e169 Mon Sep 17 00:00:00 2001 From: Tomasz Godzik Date: Wed, 22 Jan 2025 19:35:10 +0100 Subject: [PATCH 2/9] docs: apply suggestions from review --- _posts/2025-02-01-next-scala-lts.md | 38 ++++++++++++++++++++--------- 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index 6eec525cc..eed509328 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -7,16 +7,15 @@ by: Tomasz Godzik **TLDR;** -sun.misc.Unsafe, re-used in lazy val implementation, will be removed in a future -JDK one of the Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 -support +API used in lazy val implementation, will be removed in a future JDK thus one of +the Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. ## Intro For the compiler’s second LTS version, the Scala 3 compiler team will be dropping support for JDK 8 and is considering which later JDK to use. -## Reasons for the change +## Immediate motivation One of the main reasons is that recent [JEP 471](https://openjdk.org/jeps/471) stated that the memory-access methods in sun.misc.Unsafe are scheduled for @@ -28,18 +27,33 @@ which is being investigated under dawn on the compiler team that we might consider stopping to support JDK 8 altogether in a future release of Scala 3. -## Advantages +## Long term motivation Switching to a newer version of the JDK would allow both the compiler and the -Scala ecosystem to start using new features brought in by JDK 9+. This might -include a number of JEPs, which will be investigated by the team the coming -year. To check the current status take a look at the issues marked with the +Scala ecosystem to start using new features and standard library improvements +brought in by JDK 9+. This might include a number of JEPs, which will be +investigated by the team the coming year. To check the current status take a +look at the issues marked with the [JEP label](https://github.com/scala/scala3/issues?q=is%3Aissue+is%3Aopen+label%3Acompat%3Ajava%3Ajep). +Some of the features that might be interesting to the Scala community are: + +- [JEP 181](https://github.com/scala/scala3/issues/22292) will allow classes + that are logically part of the same code entity, but which are compiled to + distinct class files, to access each other's private members without the need + for Scala compiler to insert accessibility-broadening bridge methods. This is + especially useful for nested classes or companions. +- [JEP 334](https://github.com/scala/scala3/issues/22294) introduce an API to + model nominal descriptions of key class-file and run-time artifacts, which can + potentially help improve the internals of Scala 3 compiler. +- [JEP 471](https://github.com/scala/scala3/issues/9013) which adds a new API + for memory access, which can be used to replace the usage of sun.misc.Unsafe + in Scala 3. + Another advantage would be reducing the maintenance burden on tooling and library authors that currently have to take into account a large number of different versions to test and make sure that their code is performant on all of -them. +them. Thus, the benefits of this change will be felt ecosystem-wide. If we take a look at the timeline we'll see that JDK 8 was first published on 18th March 2014, which is already over 10 years ago. Technology and especially @@ -71,10 +85,10 @@ If you are using Scala 3 on JDK 8 do let us know! However the current line of LTS under 3.3.x will be supported for at least another year after the release of the next LTS version, which should give you plenty of time to migrate. -If at any point it turns out it's not possible for you to switch, be sure to -send us your feedback. +If it's not possible for you to switch, be sure to send us your feedback so that +we can figure out a way to help you migrate. -## Summary +## Discussions and further reading You can track the current work related to lazy values under [this issue](https://github.com/scala/scala3/issues/9013) and discuss the topic From 3332fd575ddb53dacf196169a17744b523996508 Mon Sep 17 00:00:00 2001 From: Tomasz Godzik Date: Fri, 24 Jan 2025 17:58:21 +0100 Subject: [PATCH 3/9] docs: Rework list of JEPs and mention more projects --- _posts/2025-02-01-next-scala-lts.md | 126 +++++++++++++++++----------- 1 file changed, 75 insertions(+), 51 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index eed509328..b05ebb021 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -7,8 +7,9 @@ by: Tomasz Godzik **TLDR;** -API used in lazy val implementation, will be removed in a future JDK thus one of -the Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. +An API used in the `lazy val` implementation will be removed in a future JDK. +Its replacement is only available on JDK 9+. Therefore, the Scala 3 Next minors +in 2025 Q4 and the next LTS will drop JDK 8 support. ## Intro @@ -17,80 +18,103 @@ dropping support for JDK 8 and is considering which later JDK to use. ## Immediate motivation -One of the main reasons is that recent [JEP 471](https://openjdk.org/jeps/471) -stated that the memory-access methods in sun.misc.Unsafe are scheduled for -removal in a future release. Currently, Scala 3 uses sun.misc.Unsafe in its -implementation of lazy values. This was needed due to compatibility with JDK 8. -In order to support later versions of JDK we will need to drop usage of Unsafe, -which is being investigated under -[this issue](https://github.com/scala/scala3/issues/9013). It also started to -dawn on the compiler team that we might consider stopping to support JDK 8 +The recent [JEP 471](https://openjdk.org/jeps/471) stated that the memory-access +methods in sun.misc.Unsafe are scheduled for removal in a future release. +Currently, Scala 3 uses sun.misc.Unsafe in its implementation of lazy values. +This was needed due to compatibility with JDK 8. In order to support JDK 25+, we +will need to drop usage of Unsafe. We are investigating the required changes +under [this issue](https://github.com/scala/scala3/issues/9013). It also started +to dawn on the compiler team that we might consider stopping to support JDK 8 altogether in a future release of Scala 3. ## Long term motivation Switching to a newer version of the JDK would allow both the compiler and the Scala ecosystem to start using new features and standard library improvements -brought in by JDK 9+. This might include a number of JEPs, which will be -investigated by the team the coming year. To check the current status take a -look at the issues marked with the +brought in by JDK 9+. brought in by JDK 9+. This might include a number of JEPs, +which the compiler team will investigate during the coming year. To check the +current status, take a look at the issues marked with the [JEP label](https://github.com/scala/scala3/issues?q=is%3Aissue+is%3Aopen+label%3Acompat%3Ajava%3Ajep). Some of the features that might be interesting to the Scala community are: - [JEP 181](https://github.com/scala/scala3/issues/22292) will allow classes that are logically part of the same code entity, but which are compiled to - distinct class files, to access each other's private members without the need - for Scala compiler to insert accessibility-broadening bridge methods. This is - especially useful for nested classes or companions. -- [JEP 334](https://github.com/scala/scala3/issues/22294) introduce an API to - model nominal descriptions of key class-file and run-time artifacts, which can - potentially help improve the internals of Scala 3 compiler. -- [JEP 471](https://github.com/scala/scala3/issues/9013) which adds a new API - for memory access, which can be used to replace the usage of sun.misc.Unsafe - in Scala 3. - -Another advantage would be reducing the maintenance burden on tooling and -library authors that currently have to take into account a large number of -different versions to test and make sure that their code is performant on all of -them. Thus, the benefits of this change will be felt ecosystem-wide. - -If we take a look at the timeline we'll see that JDK 8 was first published on -18th March 2014, which is already over 10 years ago. Technology and especially -JDKs have advanced greatly through that period and in order to stay competitive -using those advancements is a must. A lot of the existing distributions are -already stopping or will soon stop updating JDK 8 with security and other fixes, -which might directly impact issues within your business applications. + distinct class files, to access each other's private members. This is + especially useful for nested classes or companions. Currently, the Scala + compiler has to insert public bridge methods to broaden the accessibility of + those members. +- [JEP 409](https://github.com/scala/scala3/issues/22298) introduces sealed + classes. It would allow the compiler to better represent Scala's sealed trait + hierarchies. +- [JEP 441](https://github.com/scala/scala3/issues/22450) introduces new + bytecode shapes for pattern matching in Java. With them, we may be able to + optimize the code resulting from Scala pattern matches. +- [JEP 471](https://github.com/scala/scala3/issues/9013) adds a new API for + memory access. We will use it to replace the usage of `sun.misc.Unsafe` in + Scala 3. + +Dropping JDK 8 will reduce the maintenance burden on tooling and library +authors. They currently have to take into account a large number of different +versions, both for correctness and performance. Thus, the benefits of this +change will be felt ecosystem-wide. + +JDK 8 was first published on 18th March 2014, over 10 years ago. JDKs have +advanced greatly through that period. In order to stay competitive, using those +advancements is a must. A lot of the existing distributions, such as +[Oracle's one](https://www.oracle.com/java/technologies/java-se-support-roadmap.html), +have already stopped or will soon stop updating JDK 8 with security and other +fixes. Staying on JDK 8 might directly impact issues within your business +applications. Some larger projects within JVM and Scala ecosystems have already dropped JDK 8 -support. And while it's always possible to not update your libraries and Scala -version, which will avoid having to switch to a newer JDK, it's highly -discouraged as it will make you vulnerable to potential security risks. +support in favor of JDK 11 or even 17. Some examples are: + +- [Spark 4](https://github.com/apache/spark/pull/43005#issuecomment-1731344040) + will require JDK 17 +- [Play Framework](https://github.com/playframework/playframework/issues/11078) + requires JDK 11 and + [will require JDK 17](https://github.com/playframework/playframework/issues/12179) + in the next major release +- [Akka](https://github.com/akka/akka/pull/32127) requires JDK 11 +- [Spring 6](https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga) + will require JDK 17 +- [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 +- [Apache Kafka](https://kafka.apache.org/documentation/#java) requires JDK 11 +- [Hibernate](https://hibernate.org/orm/releases/6.6/) requires JDK 11 and the + next version will require JDK 17 +- [ZIO](https://github.com/zio/zio/pull/8434) requires JDK 11 +- [Li Haoyi's ecosystem](https://github.com/com-lihaoyi) requires JDK 11 across + the board + +It is always possible not to update your libraries and compiler version, which +will avoid having to switch to a newer JDK. However, it is highly discouraged, +as it will make you vulnerable to potential security risks. ## Plan for making the switch The current plan is to drop support of JDK 8 in one of the future minor releases -of Scala 3 and in the next LTS. The JDK will be either 11 or 17 depending on the -community feedback and our investigations. The current estimate for the next LTS -is Q4 2025. +of Scala 3 and in the next LTS. The JDK will be either 11 or 17, depending on +the community feedback and our investigations. The current estimate for the next +LTS is Q4 2025. -One of the major challenges here will be making sure that we are still able to -use libraries compiled with earlier JDK 8 compatible Scala 3 versions in the -versions with a new implementation of lazy values, which is not reliant on -sun.misc.Unsafe. +One major challenge will be to preserve backward compatibility. As we change the +encoding of `lazy val`s, we must still be able to use libraries compiled with +earlier Scala 3 versions. ## How does it affect me? -If you are using Scala 3 on JDK 8 do let us know! However the current line of -LTS under 3.3.x will be supported for at least another year after the release of -the next LTS version, which should give you plenty of time to migrate. +The current line of LTS under 3.3.x will be supported for at least another year +after the release of the next LTS version. That should give you plenty of time +to migrate. After that, no more security fixes will be available for Scala 3 +versions supporting JDK 8. If you are using Scala 3 on JDK 8, do let us know! -If it's not possible for you to switch, be sure to send us your feedback so that -we can figure out a way to help you migrate. +If it is not possible for you to switch, be sure to send us your feedback so +that we can figure out a way to help you migrate. ## Discussions and further reading You can track the current work related to lazy values under -[this issue](https://github.com/scala/scala3/issues/9013) and discuss the topic -under soon to be posted thread on the +[this issue](https://github.com/scala/scala3/issues/9013). Discussions on the +topic of dropping JDK 8 support will soon be available on the [Scala contributors forum](https://contributors.scala-lang.org/) From b92e250052e9b709c72e3c5c3d1d755ae7a7b2a8 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Tue, 28 Jan 2025 14:03:59 -0800 Subject: [PATCH 4/9] separate the projects lists into Java and Scala --- _posts/2025-02-01-next-scala-lts.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index b05ebb021..ff0c95e7c 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -68,7 +68,17 @@ fixes. Staying on JDK 8 might directly impact issues within your business applications. Some larger projects within JVM and Scala ecosystems have already dropped JDK 8 -support in favor of JDK 11 or even 17. Some examples are: +support in favor of JDK 11 or even 17. + +Java examples include: + +- [Spring 6](https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga) + will require JDK 17 +- [Hibernate](https://hibernate.org/orm/releases/6.6/) requires JDK 11 and the + next version will require JDK 17 +- [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 + +Scala examples include: - [Spark 4](https://github.com/apache/spark/pull/43005#issuecomment-1731344040) will require JDK 17 @@ -77,12 +87,7 @@ support in favor of JDK 11 or even 17. Some examples are: [will require JDK 17](https://github.com/playframework/playframework/issues/12179) in the next major release - [Akka](https://github.com/akka/akka/pull/32127) requires JDK 11 -- [Spring 6](https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga) - will require JDK 17 -- [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 - [Apache Kafka](https://kafka.apache.org/documentation/#java) requires JDK 11 -- [Hibernate](https://hibernate.org/orm/releases/6.6/) requires JDK 11 and the - next version will require JDK 17 - [ZIO](https://github.com/zio/zio/pull/8434) requires JDK 11 - [Li Haoyi's ecosystem](https://github.com/com-lihaoyi) requires JDK 11 across the board From 4e2a11c9ea033f2268030d4b6a3d06c88d6c959b Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Tue, 28 Jan 2025 14:06:58 -0800 Subject: [PATCH 5/9] add two more Java projects --- _posts/2025-02-01-next-scala-lts.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index ff0c95e7c..feef45658 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -76,7 +76,9 @@ Java examples include: will require JDK 17 - [Hibernate](https://hibernate.org/orm/releases/6.6/) requires JDK 11 and the next version will require JDK 17 +- [Jetty](https://jetty.org/docs/jetty/12/index.html) requires JDK 17 - [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 +- [Quarkus](https://quarkus.io/blog/quarkus-3-7-released/) requires JDK 17 Scala examples include: From baf2899e375cd18f5c94692216fcf12681f5aad8 Mon Sep 17 00:00:00 2001 From: Seth Tisue Date: Tue, 28 Jan 2025 14:11:57 -0800 Subject: [PATCH 6/9] more Java projects --- _posts/2025-02-01-next-scala-lts.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index feef45658..57563bbce 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -78,7 +78,10 @@ Java examples include: next version will require JDK 17 - [Jetty](https://jetty.org/docs/jetty/12/index.html) requires JDK 17 - [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 +- [JavaFX](https://gluonhq.com/products/javafx/) requires JDK 21 +- [Vaadin](https://github.com/vaadin/platform/releases/tag/24.6.0) requires JDK 17 - [Quarkus](https://quarkus.io/blog/quarkus-3-7-released/) requires JDK 17 +- [TensorFlow](https://github.com/tensorflow/java) requires JDK 11 Scala examples include: From 54870ec37413d2d15c1ed27ea4a9765e8be12bd4 Mon Sep 17 00:00:00 2001 From: tgodzik Date: Thu, 30 Jan 2025 14:35:07 +0100 Subject: [PATCH 7/9] chore: Add more review comments --- _posts/2025-02-01-next-scala-lts.md | 55 +++++++++++++++-------------- 1 file changed, 29 insertions(+), 26 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index 57563bbce..fee4597ac 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -1,39 +1,39 @@ --- category: announcement permalink: /news/next-scala-lts.html -title: "Next Scala 3 LTS version" +title: "Next Scala 3 LTS version will increase minimum required JDK version" by: Tomasz Godzik --- -**TLDR;** +**TL;DR** -An API used in the `lazy val` implementation will be removed in a future JDK. -Its replacement is only available on JDK 9+. Therefore, the Scala 3 Next minors -in 2025 Q4 and the next LTS will drop JDK 8 support. +The Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. We are seeking feedback on whether the new minimum JDK should be 11 or 17. ## Intro For the compiler’s second LTS version, the Scala 3 compiler team will be -dropping support for JDK 8 and is considering which later JDK to use. +dropping support for JDK 8 and is considering which later JDK to require — +perhaps 11, perhaps 17. ## Immediate motivation The recent [JEP 471](https://openjdk.org/jeps/471) stated that the memory-access -methods in sun.misc.Unsafe are scheduled for removal in a future release. -Currently, Scala 3 uses sun.misc.Unsafe in its implementation of lazy values. +methods in `sun.misc.Unsafe` are scheduled for removal in a future release. +Currently, Scala 3 uses `sun.misc.Unsafe` in its implementation of lazy values. This was needed due to compatibility with JDK 8. In order to support JDK 25+, we -will need to drop usage of Unsafe. We are investigating the required changes -under [this issue](https://github.com/scala/scala3/issues/9013). It also started -to dawn on the compiler team that we might consider stopping to support JDK 8 -altogether in a future release of Scala 3. +will need to drop usage of `Unsafe`. We are investigating the required changes +under [this issue](https://github.com/scala/scala3/issues/9013). + +It also started to dawn on the compiler team that we might consider dropping +support for JDK 8 altogether in a future release of Scala 3. ## Long term motivation Switching to a newer version of the JDK would allow both the compiler and the Scala ecosystem to start using new features and standard library improvements -brought in by JDK 9+. brought in by JDK 9+. This might include a number of JEPs, -which the compiler team will investigate during the coming year. To check the -current status, take a look at the issues marked with the +brought in by JDK 9+. This might include a number of JEPs (JDK Enhancement +Proposals), which the compiler team will investigate during the coming year. To +check the current status, take a look at the issues marked with the [JEP label](https://github.com/scala/scala3/issues?q=is%3Aissue+is%3Aopen+label%3Acompat%3Ajava%3Ajep). Some of the features that might be interesting to the Scala community are: @@ -73,13 +73,14 @@ support in favor of JDK 11 or even 17. Java examples include: - [Spring 6](https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga) - will require JDK 17 + requires JDK 17 - [Hibernate](https://hibernate.org/orm/releases/6.6/) requires JDK 11 and the next version will require JDK 17 - [Jetty](https://jetty.org/docs/jetty/12/index.html) requires JDK 17 - [Logback](https://logback.qos.ch/dependencies.html) requires JDK 11 - [JavaFX](https://gluonhq.com/products/javafx/) requires JDK 21 -- [Vaadin](https://github.com/vaadin/platform/releases/tag/24.6.0) requires JDK 17 +- [Vaadin](https://github.com/vaadin/platform/releases/tag/24.6.0) requires JDK + 17 - [Quarkus](https://quarkus.io/blog/quarkus-3-7-released/) requires JDK 17 - [TensorFlow](https://github.com/tensorflow/java) requires JDK 11 @@ -98,15 +99,15 @@ Scala examples include: the board It is always possible not to update your libraries and compiler version, which -will avoid having to switch to a newer JDK. However, it is highly discouraged, +will avoid having to switch to a newer JDK. However, that is highly discouraged, as it will make you vulnerable to potential security risks. ## Plan for making the switch The current plan is to drop support of JDK 8 in one of the future minor releases -of Scala 3 and in the next LTS. The JDK will be either 11 or 17, depending on -the community feedback and our investigations. The current estimate for the next -LTS is Q4 2025. +of Scala 3 and in the next LTS. The new minimum JDK will be either 11 or 17, +depending on the community feedback and our investigations. The current estimate +for the next LTS is Q4 2025. One major challenge will be to preserve backward compatibility. As we change the encoding of `lazy val`s, we must still be able to use libraries compiled with @@ -117,14 +118,16 @@ earlier Scala 3 versions. The current line of LTS under 3.3.x will be supported for at least another year after the release of the next LTS version. That should give you plenty of time to migrate. After that, no more security fixes will be available for Scala 3 -versions supporting JDK 8. If you are using Scala 3 on JDK 8, do let us know! +versions supporting JDK 8. -If it is not possible for you to switch, be sure to send us your feedback so -that we can figure out a way to help you migrate. +If you are using Scala 3 on JDK 8, do let us know! If it is not possible for you +to switch, be sure to send us your feedback so that we can figure out a way to +help you migrate. ## Discussions and further reading You can track the current work related to lazy values under -[this issue](https://github.com/scala/scala3/issues/9013). Discussions on the -topic of dropping JDK 8 support will soon be available on the +[this issue](https://github.com/scala/scala3/issues/9013). + +Discussions on the topic of dropping JDK 8 support will soon be available on the [Scala contributors forum](https://contributors.scala-lang.org/) From 273645f48f940d1b777766f91b99f5623aef1772 Mon Sep 17 00:00:00 2001 From: tgodzik Date: Fri, 31 Jan 2025 13:14:25 +0100 Subject: [PATCH 8/9] chore: Add link to the contributors topic --- _posts/2025-02-01-next-scala-lts.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index fee4597ac..b79007452 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -7,7 +7,8 @@ by: Tomasz Godzik **TL;DR** -The Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. We are seeking feedback on whether the new minimum JDK should be 11 or 17. +The Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. We +are seeking feedback on whether the new minimum JDK should be 11 or 17. ## Intro @@ -129,5 +130,5 @@ help you migrate. You can track the current work related to lazy values under [this issue](https://github.com/scala/scala3/issues/9013). -Discussions on the topic of dropping JDK 8 support will soon be available on the -[Scala contributors forum](https://contributors.scala-lang.org/) +Discussion on the topic of dropping JDK 8 support is available on the +[Scala contributors forum](https://contributors.scala-lang.org/t/next-scala-3-lts-version-will-increase-minimum-required-jdk-version) From 4bec6f05bc39fa113282943e5dd4b12ec24cf90d Mon Sep 17 00:00:00 2001 From: tgodzik Date: Fri, 31 Jan 2025 13:22:19 +0100 Subject: [PATCH 9/9] chore: Add back Seth's chanages --- _posts/2025-02-01-next-scala-lts.md | 50 ++++++++++++----------------- 1 file changed, 21 insertions(+), 29 deletions(-) diff --git a/_posts/2025-02-01-next-scala-lts.md b/_posts/2025-02-01-next-scala-lts.md index b79007452..700867829 100644 --- a/_posts/2025-02-01-next-scala-lts.md +++ b/_posts/2025-02-01-next-scala-lts.md @@ -1,7 +1,7 @@ --- category: announcement permalink: /news/next-scala-lts.html -title: "Next Scala 3 LTS version will increase minimum required JDK version" +title: "Next Scala 3 LTS series will increase minimum required JDK version" by: Tomasz Godzik --- @@ -10,22 +10,16 @@ by: Tomasz Godzik The Scala 3 Next minors in 2025 Q4 and the next LTS will drop JDK 8 support. We are seeking feedback on whether the new minimum JDK should be 11 or 17. -## Intro - -For the compiler’s second LTS version, the Scala 3 compiler team will be -dropping support for JDK 8 and is considering which later JDK to require — -perhaps 11, perhaps 17. - ## Immediate motivation -The recent [JEP 471](https://openjdk.org/jeps/471) stated that the memory-access -methods in `sun.misc.Unsafe` are scheduled for removal in a future release. -Currently, Scala 3 uses `sun.misc.Unsafe` in its implementation of lazy values. -This was needed due to compatibility with JDK 8. In order to support JDK 25+, we -will need to drop usage of `Unsafe`. We are investigating the required changes -under [this issue](https://github.com/scala/scala3/issues/9013). +The memory-access methods in `sun.misc.Unsafe` are scheduled for removal in a +future JDK, as stated in the recent [JEP 471](https://openjdk.org/jeps/471). +Currently, Scala 3 uses `sun.misc.Unsafe` in its implementation of `lazy val`. +In order to support JDK 25+, we will need to drop usage of `Unsafe`. We are +investigating the required changes under +[this issue](https://github.com/scala/scala3/issues/9013). -It also started to dawn on the compiler team that we might consider dropping +It then started to dawn on the compiler team that we might consider dropping support for JDK 8 altogether in a future release of Scala 3. ## Long term motivation @@ -40,11 +34,10 @@ check the current status, take a look at the issues marked with the Some of the features that might be interesting to the Scala community are: - [JEP 181](https://github.com/scala/scala3/issues/22292) will allow classes - that are logically part of the same code entity, but which are compiled to - distinct class files, to access each other's private members. This is - especially useful for nested classes or companions. Currently, the Scala - compiler has to insert public bridge methods to broaden the accessibility of - those members. + that are logically connected, to access each other's private members. This + could be useful for representing nested classes and companion objects. + (Currently, the Scala compiler has to insert public bridge methods to broaden + the accessibility of those members.) - [JEP 409](https://github.com/scala/scala3/issues/22298) introduces sealed classes. It would allow the compiler to better represent Scala's sealed trait hierarchies. @@ -60,15 +53,16 @@ authors. They currently have to take into account a large number of different versions, both for correctness and performance. Thus, the benefits of this change will be felt ecosystem-wide. -JDK 8 was first published on 18th March 2014, over 10 years ago. JDKs have -advanced greatly through that period. In order to stay competitive, using those -advancements is a must. A lot of the existing distributions, such as -[Oracle's one](https://www.oracle.com/java/technologies/java-se-support-roadmap.html), +JDK 8 was first published in 2014, over 10 years ago. JDKs have advanced greatly +since then. In order to stay competitive, using those advancements is a must. A +lot of the existing distributions, including +[Oracle's own](https://www.oracle.com/java/technologies/java-se-support-roadmap.html), have already stopped or will soon stop updating JDK 8 with security and other -fixes. Staying on JDK 8 might directly impact issues within your business -applications. +fixes. It is of course possible not to update your libraries and compiler +version, to avoid having to switch to a newer JDK. However, that is highly +discouraged, as it will make you vulnerable to potential security risks. -Some larger projects within JVM and Scala ecosystems have already dropped JDK 8 +Some larger projects in the Java and Scala ecosystems have already dropped JDK 8 support in favor of JDK 11 or even 17. Java examples include: @@ -99,9 +93,7 @@ Scala examples include: - [Li Haoyi's ecosystem](https://github.com/com-lihaoyi) requires JDK 11 across the board -It is always possible not to update your libraries and compiler version, which -will avoid having to switch to a newer JDK. However, that is highly discouraged, -as it will make you vulnerable to potential security risks. +This shows that the rest of the industry is already moving away from JDK 8. ## Plan for making the switch