Next Scala 3 LTS version will increase minimum required JDK version

Language Design
41

Yes please — as best I can recall, this is the first I’m hearing about it.

42

Note that this is certainly an Android bug. But we could mitigate it by e.g. providing a flag to un-specialize lambdas. Specifically, this is one of the failing parts:

  def number: Parser[Double] = regexp ^^ { _.toDouble }

When this code is executed, it fails with:

Verifier rejected class scas.scripting.DoubleParser$$$ExternalSyntheticLambda0:double scas.scripting.DoubleParser$$$ExternalSyntheticLambda0.apply(java.lang.String):
Verification error in double scas.scripting.DoubleParsers$$$ExternalSyntheticLambda0.apply(java.lang.String): [0xFFFFFFFF] wide register index out of range (1+1 >= 2)

Decompiling with apktool and looking at DoubleParsers$$$ExternalSyntheticLambda0.smali

.method public final bridge synthetic apply(Ljava/lang/String;)D
    .locals 0
    .line 0
    invoke-virtual {p0, p1}, Lscas/scripting/DoubleParsers$$$ExternalSyntheticLambda0;->apply(Ljava/lang/Object;)Ljava/lang/Object;
    move-result-object p1
    check-cast p1, D
    return-wide p1
.end method

We see that there is a check cast to D from java.lang.Object. If instead of scala Double we define the Parser above as returning java.lang.Double (which is an Object) then the problem vanishes.

3 Likes
43

Consider reporting this on the android bug tracker, they fixed an issue triggered by Scala I reported (Google Issue Tracker), so there’s a chance they’ll fix this one too.

4 Likes
44

Thanks, I will do it. I will also look at the outcome with the equivalent Java code.

By the way, one more argument to remain at JDK11 (or at least provide an option if not the default) is that proguard does not support JDK17.

45

What do you mean? It appears to support all recent Java versions.

46

Silly me, it’s just the Debian package that is lagging behind (6.2.2). Thanks for noticing.

2 Likes
47

is it the same as Illegal arguments for bootstrap method for invokedynamic · Issue #15736 · scala/scala3 · GitHub ? (a PR for it came in today)

48

Yes it seems so.

49

Probably everyone has already expressed their opinion on the topic and decision was already made, however still want to add some perspective:

What I think is the best for Scala is to adopt tip and tail approach from Java, so newer Scala versions can fully leverage advancements in JVM development and potentially ship optimizations only available in newer versions (maybe through Multi-Release JAR), like point mentioning Unsafe when there’re more performant optimizations available with Var/Method Handles.

Otherwise, What I envision is Scala won’t be able to keep up with optimizations and advancements in Java (e.g. Valhalla, Code Reflections, Panama, AOT, etc) and what might happen is people going to start dropping Scala in favor of Vanilla Java in order to leverage better footprint and performance and potentially better integration with native code or hardware (e.g. GPU for AI).

5 Likes
50

I wanted to thank everyone for their input, I think this was quite a constructive discussion.

We reached a decisions during the core meeting and it has just been announced in JDK 17 will be the next minimum version required by Scala 3 | The Scala Programming Language

11 Likes
51

Is there a plan when JDK 17 will get replaced with JDK 21, JDK 25 or JDK 29 as minimal JDK version?

52

No plans currently, we will most likely decide on that when another LTS is planned.