Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
runtimelab
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The implementation uses invokedynamic (which has been available for ages) and dispatches to java.lang.runtime.SwitchBootstraps#typeSwitch(…):
https://docs.oracle.com/en/java/javase/20/docs/api/java.base......)
The concrete implementation in doTypeSwitch currently says “Dumbest possible strategy”:
https://github.com/openjdk/jdk/blob/master/src/java.base/sha...
There is no @IntrinsicCandidate, so I don't expect Hotspot to special-case any of this yet. The machinery described so far merely computes an array index, and there is a subsequent lookupswitch opcode that selects the appropriate case body to run.
I'd be somewhat surprised if Hotspot could unroll the checking loop and eliminate the subsequent switch. So the Java implementation looks rather bad from a performance point of view (but it's obviously designed for compact bytecode and future optimization). Scala could certainly do the same (the magic of invokedynamic is that it's not magic), and probably much better in many cases, even on current Hotspot.
5. First-class support for asynchronous programming. With "suspend" in Kotlin and a current prototype being done in Scala 3:
- REPO: https://github.com/lampepfl/async | SLIDES: https://github.com/lampepfl/async/blob/main/scalar-slides.pd... | YOUTUBE TALK: https://www.youtube.com/watch?v=0Fm0y4K4YO8
While virtual threads will be stable in Java 21, Structured Concurrency is still a preview feature. You probably won't see it in production anytime soon.
Preview features require a special flag when compiling and running them, and they won't run on newer versions of the JVM. I don't expect to see StructuredTaskScope in common production use before the next LTS version is out.
But it doesn't mean you cannot have structured concurrency before that. Even in language that mostly enforce Structured Concurrency like Kotlin, it's still a library feature. Even the original blog post which formulated this concept, described a library that implemented structured concurrency for Python[1]. You can pretty easily implement structured concurrency yourself by creating your own implementation of StructuredTaskScope, if you need it right now. You can even structured concurrency in C#[2] or Go[3].
[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[2] https://github.com/StephenCleary/StructuredConcurrency
[3] https://github.com/sourcegraph/conc
While virtual threads will be stable in Java 21, Structured Concurrency is still a preview feature. You probably won't see it in production anytime soon.
Preview features require a special flag when compiling and running them, and they won't run on newer versions of the JVM. I don't expect to see StructuredTaskScope in common production use before the next LTS version is out.
But it doesn't mean you cannot have structured concurrency before that. Even in language that mostly enforce Structured Concurrency like Kotlin, it's still a library feature. Even the original blog post which formulated this concept, described a library that implemented structured concurrency for Python[1]. You can pretty easily implement structured concurrency yourself by creating your own implementation of StructuredTaskScope, if you need it right now. You can even structured concurrency in C#[2] or Go[3].
[1] https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[2] https://github.com/StephenCleary/StructuredConcurrency
[3] https://github.com/sourcegraph/conc
There’s https://semver.org/, which Java unfortunately has not chosen to follow. As joaonmatos pointed out, 8->9 was the most painful major version change, and I think there have been a couple others when deprecated features were fully removed.
Kotlin's standard collection are "immutable collections" only in the sense that they are read-only. Adding an element to a Kotlin immutable set copies the whole thing,
https://github.com/JetBrains/kotlin/blob/924c28507067cbfbf78...
This is not that different from Java unmodifiable. In contrast the Scala immutable Set supports constant time addition,
https://docs.scala-lang.org/overviews/collections-2.13/perfo...
This isn't just an ivory tower concern either. Because Kotlin immutables aren't actually immutable (they just don't expose mutation interfaces) this means that if I get a ref to an immutable Set, I can't modify it but I can't rely on it not changing because it's still back by a mutable one.
Green Threads Experiment if anyone is interested in what they've done in .NET: https://github.com/dotnet/runtimelab/issues/2057
Personally Asyc/Await is the only thing keeping me from the C# ecosystem.