Just published: Signature polymorphic methods in Scala | The Scala Programming Language
For users, the upshot is that is there were certain methods in the Java reflection API that weren’t callable from Scala 3 — but now they are, as of Scala 3.3.0.
But the blog post goes into detail about those methods and about how we implemented support for them. It may be of interest to JVM aficionados, Scala and Java language mavens, and compiler hackers.
VarHandle is from Java 9 but the blog post states 11, did I missed something?
Interesting read. Didn’t know about that until now… Thanks for the write up!
Do I read it right, Java has a feature to kind of specialize method calls?
Could this be exploited in some creative ways? For example to specialized Scala methods to gain performance?
No, as mentioned in the blog post:
[…] users are not allowed to define their own signature polymorphic methods. Only the Java standard library can do that, and so far, the creators of Java have only used the feature in these two classes [MethodHandle and VarHandle].
I’ve seen this part.
But only because Java can’t do something doesn’t mean Scala can’t do it. (My understanding of “users” here was “Java users”.)
I didn’t look up the details until now. Maybe someone could quickly explain: How does the “magic” work? Does the Java std.lib get recognized by the JVM in any way? How? What does it do exactly to use this feature?
invokeExact/… are native methods with custom implementations hardcoded in HotSpot, there’s nothing we can do to repurpose that at the bytecode level.
Nevertheless thanks for explaining!
So they spec-ed outright magic behavior. Well…
Still interesting what the JVM does internally, as this looks to me like kind of a mechanism for specialization.
You’re right, and I just fixed the blog post to say 9. Thank you.
I think I got confused because we did have some to make some adjustments when 11 came out: Follow JDK 11+ spec for signature polymorphic methods by lrytz · Pull Request #9530 · scala/scala · GitHub