I really like the @uncheckedOverride.

Cool. I'll bring it up at the meeting on Wed, if we do it then we should also do it on Scala 3.

Maybe a separate issue, but the unchecked package conflicts with scala.unchecked.

It would be nice to put the new class in annotation.

Maybe someday we'll get the feature that @uncheckedOverride means @annotation.uncheckedOverride.

And maybe annotation.unchecked will be deprecated sooner than later.

The current idiom is import annotation.{unchecked as _, *}.

I'll leave it there in company with the other uncheckedX annotations.

I'll bring it up at the meeting on Wed, if we do it then we should also do it on Scala 3.

The board agrees.

@lrytz is the compilation failure in Spire at https://scala-ci.typesafe.com/job/scala-2.12.x-jdk21-integrate-community-build/1214/artifact/logs/spire-build.log expected?

Ah, the 2.12.x build... Hm.

This PR changes the signature from def max(x: T, y: T): T to def max[U <: T](x: U, y: U): U. This is the signature that the Java method has in JDK 26, and it's also the signature we have on 2.13.x. The change is binary compatible but not source compatible.

If we want to be able to compile the 2.12 standard library on Java 26, I don't see another way. Even if we don't, I'm not sure it would work to keep the old signature in the 2.12 standard library and allow users to compile their Ordering subclasses on Java 26.

So changing the signatures looks like the cleanest solution. Do you think the source compat breakage is acceptable?

Ah, the 2.12.x build... Hm.

This PR changes the signature from def max(x: T, y: T): T to def max[U <: T](x: U, y: U): U. This is the signature that the Java method has in JDK 26, and it's also the signature we have on 2.13.x. The change is binary compatible but not source compatible.

If we want to be able to compile the 2.12 standard library on Java 26, I don't see another way. Even if we don't, I'm not sure it would work to keep the old signature in the 2.12 standard library and allow users to compile their Ordering subclasses on Java 26.

So changing the signatures looks like the cleanest solution. Do you think the source compat breakage is acceptable?

Can't we just say 2.12.x will not work on Java 26? If people want to move to a newer version of Java, they can move to 2.13.x or 3.x. I know it's not an easy migration but we should upper-bound the JVM version at some point.

They can't move their sbt build away from 2.12.x, though.

They can't move their sbt build away from 2.12.x, though.

sbt 2.x will be released soon, right? So that will take care of it.

If we want to be able to compile the 2.12 standard library on Java 26

I suggest we should not care about that for 2.12. In short, I agree with Hamza.

They can't move their sbt build away from 2.12.x, though.

In some other contexts that might be a good point, but in this particular context.... meh, I don't think people actually need to define custom Orderings in their build definitions.

What should 2.12's level of support for JDK 26+ be?

For 2.12.x, I think it's worth supporting JDK 25 whenever the effort involved is reasonable.

But JDK 26? I suggest we consider JDK 26+ out of scope for 2.12, unless perhaps we receive specific complaints or requests. I don't think we should be proactive about building or testing 2.12 on 26+. (Recall that we aren't even running the Scala 2.12 community build on 25, let alone 26; we stopped at 21.)

If we do get specific bug reports relating to 2.12 on 26+, we can triage them then. For any individual issue that is reported, our options will be:

1. fix it ourselves
2. merge a fix if a volunteer contributes one and we deem it safe
3. refuse to go anywhere near it (unless actual funding is involved!) as 2.12 is so close to being EOL, 26 is not LTS, and Java 29 LTS won't be along for several years

Do you think the source compat breakage is acceptable?

I would rather just not support 26+ than break source compat here.

I'm fine with adding @uncheckedOverride for people to use if they want, but changing signatures in 2.12 stdlib just seems like unnecessary jank to me. We should not be messing with it IMO.

(Sorry, yes, I know I'm late to the party, only expressing this opinion now, after the PR has been merged...)

If we want to be able to compile the 2.12 standard library on Java 26

I suggest we should not care about that for 2.12. In short, I agree with Hamza.

They can't move their sbt build away from 2.12.x, though.

In some other contexts that might be a good point, but in this particular context.... meh, I don't think people actually need to define custom Orderings in their build definitions.

What should 2.12's level of support for JDK 26+ be?

For 2.12.x, I think it's worth supporting JDK 25 whenever the effort involved is reasonable.

But JDK 26? I suggest we consider JDK 26+ out of scope for 2.12, unless perhaps we receive specific complaints or requests. I don't think we need to be proactive about building or testing 2.12 on 26+. (Recall that we aren't even running the Scala 2.12 community build on 25, let alone 26; we stopped at 21.)

If we do get specific bug reports relating to 2.12 on 26+, we can triage them then. The options of course being:

1. fix it ourselves
2. merge a fix if a volunteer contributes one and we deem it safe
3. refuse to go anywhere near it (unless actual funding is involved!) as 2.12 is so close to being EOL, 26 is not LTS, and Java 29 LTS won't be along for several years

+1. This could be perceived as the first step to EOL 2.12.x (setting a limit on the JVM). Saying Java 25 is more than fine in my opinion.

Saying Java 25 is more than fine in my opinion.

and if we do make that decision, we could communicate it to the public in two places:

• in the 2.12.21 release notes
• https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html

Saying Java 25 is more than fine in my opinion.

and if we do make that decision, we could communicate it to the public in two places:

• in the 2.12.21 release notes
• https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html

Let's add it in the agenda for next week's core meeting for the decision. /cc @Gedochao @tgodzik

IMO, as long as we support 2.12 we need to make sure 2.12 compiled code runs on the latest released Java version. We cannot announce a 2.12 EOL while sbt 1 ist still in wide use (https://www.scala-lang.org/development/#scala-212-maintenance), and once we announce it, support will still continue for another year. So it doesn't seem unlikely we will end up supporting Java 29 (September 27).

We can make a distinction between running 2.12 compiled code and compiling 2.12 code, but we should only do that if there's a strong reason. It could lead to surprises for users, and it could also make testing more complicated for us and for the community.

In this particular case, I think we should consider what will cause more pain overall: changing the signature of min/max, or dropping support for compiling on Java >25. I don't expect there to be a lot of min/max overrides out there, so I think the change will not cause a lot of problems.

fwiw, I noticed that Spire dropped Scala 2.12 all the way back in 2021 :-)

About the signature changes, there is a middle path: we could revert the signature change for now, for 2.12.21 which is imminent, but consider adding it again by the time JDK 26 final is released. At present, we can't be confident that Oracle won't back out the change; 26 is still early in the early-access phase. There won't be a 26 release candidate until February 2026, with the final release expected in March, as per https://openjdk.org/projects/jdk/26/

Agree.

To show that the issue is real: the following trait cannot be compiled with Scala 2.12 on Java 26:

trait O[T] extends scala.math.Ordering[T] {
  override def max(x: T, y: T): T = x
}

error: name clash between defined and inherited member:
<defaultmethod> def max[U <: T](x$1: U,x$2: U): U in trait Comparator and
override def max(x: T,y: T): T at line 2
have same type after erasure: (x$1: Object, x$2: Object)Object

At present, we can't be confident that Oracle won't back out the change; 26 is still early in the early-access phase

JDK 26 final is out and still has the signature change, as seen at #11234

so @lrytz, I reviewed the discussion here and I don't really have any new thoughts. personally I'd still be fine with just ignoring JDK 26 on 2.12.x, but I can certainly see why you might decide differently.

about sbt 1 on JDK 26, I'll just say that it doesn't bother me unless actual users are actually complaining... and as you already said, I don't think anyone actually needs to override min/max in their build definition 🤷