Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -279,6 +279,8 @@ object TypelevelSettingsPlugin extends AutoPlugin {
)
}

val log = streams.value.log

scalaVersion.value match {
case V(V(2, 11, _, _)) =>
oldTargetOption
Expand All @@ -296,7 +298,20 @@ object TypelevelSettingsPlugin extends AutoPlugin {
releaseOption

case V(V(3, minor, _, _)) if minor >= 2 =>
javaOutputVersionOption
if (minor <= 7) {
javaOutputVersionOption
} else {
// https://www.scala-lang.org/news/next-scala-lts-jdk.html
tlJdkRelease.value match {
case Some(n) if n >= 17 =>
javaOutputVersionOption
case Some(n) =>
log.warn(s"tlJdkRelease is ${n} but scala ${scalaVersion.value} require JDK 17")
Seq.empty
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Seq.empty
Seq("-java-output-version", 17)

I think returning Seq.empty here is the wrong behavior. Instead, we should bump the JDK release to 17.

To explain why: developers specify this flag so that the compiler prevents them from using JDK APIs that are too new. For example, APIs introduced in Java 21. Even if a JDK release version of 8 or 11 is no longer compatible with Scala 3.8+, we should still ensure that the compiler will prevent the use of APIs from JDKs >17.

In fact, I would even say the warning would just be noise and we can make this adjustment silently. By choosing to use Scala 3.8+, the developer is already opting-in to minimum JDK 17+.

case None =>
Seq.empty
}
}

case _ =>
Seq.empty
Expand Down
Loading