Upgrade mockito-core to 5.18.0, add support for JDK 17 and 21, drop Scala 2.11 and JDK 8

[jozic]

fixes #350
fixes #515
fixes #520
fixes #556
closes #517

[TimvdLippe]

Only 1 small comment. The rest LGTM! Thanks for the fixes.

[TimvdLippe]

We should make this a 2.0.* release, since we are dropping support for various configurations.

[jozic]

Sure, will update

Should we then also drop some long time deprecated methods?

[jozic]

Or I guess, we can do that in 2.0.1 as well :)

[jozic]

@TimvdLippe bumped version to 2.0.0
let me know if you want to drop deprecated methods as part of this release

cc @ultrasecreth

[TimvdLippe]

Right. Let's drop these deprecated methods as well indeed. All of them appear to have appropriate replacements, so it should be doable for users to migrate. Thanks again for all the effort in getting this project up-to-date again

[jozic]

@TimvdLippe I will send a separate commit to this PR and I suggest we don't squash those commits to keep history clean and easy to navigate

[jozic]

@TimvdLippe I've dropped all the deprecated methods with replacements, but kept isNull and isNotNull as they are deprecated because of idiomatic reasons and don't have replacements.

also, not sure why but seems like Gradle wrapper check is unstable

[TimvdLippe]

Great, thanks!

[TimvdLippe]

@jozic Seems like by bumping the Java version of the release job to 17, it now fails: https://github.com/mockito/mockito-scala/actions/runs/15277155793/job/42966910185 That's because we still use Gradle 6 (old!). Can you update our Gradle wrapper to the latest version as well and create a new PR? Thanks!

[jozic]

@TimvdLippe you made the change in #560, right?

Also, can you think of a way to automatically check depending projects like mockito-scala, mockito-kotlin, etc when mockito-core is changed? Ideally when PR is opened or at least when a new version is released

[TimvdLippe]

@jozic No I didn't upgrade Gradle. I only upgraded the GitHub action that verifies Gradle according to the checksum.

We expect them as normal consumers, e.g. they shouldn't break. Of course that sometimes is more tricky than we would like, but in general we strive to never break our users including our own dependent artifacts.