Java 21: The Nice, the Meh, and the Momentous

The context switch time is much smaller, so yes, better performance.

The relationship between throughput, latency, and concurrency in servers is expressed via Little's theorem. If your server is written in the thread-per-request style -- the only style for which the platform offers built-in language, VM, and tooling support -- then the most important factor affecting maximum throughput is the number of threads you can have (until, of course, the hardware is fully utilised). Being able to support many threads is the most effective improvement to server throughput you can offer.

See: Why User-Mode Threads Are Good for Performance https://youtu.be/07V08SB1l8c

"With the currency being the same, I keep thinking a salary of $50k/year is the same as that of $500k/year. Are there any other actual differences?"

Just as with performance improvements [1][2][3][4], the actual impact on the user experience is non-linear and often hard to predict. In the case of virtual threads, you go from needing to consciously work around a limited amount of available threads to spawning one per request and moving on.

[1]: https://youtu.be/4XpnKHJAok8?t=3026

[2]: "These tests are fast enough that I can hit enter (my test-running keystroke) and have a response before I have time to think. It means that the flow of my thoughts never breaks." - https://news.ycombinator.com/item?id=7676948

[3]: https://news.ycombinator.com/item?id=37277885

[4]: "Go’s execution tracer has suffered from high overhead since its inception in 2014. Historically this has forced potential users to worry about up to 20% of CPU overhead when turning it on. Due to this, it's mostly been used in test environments or tricky situations rather than gaining adoption as a continuous profiling signal in production." - https://blog.felixge.de/waiting-for-go1-21-execution-tracing...

Do you know if clojure will be adopting these virtual threads, or still using the macro-based approach?

It's somewhat unfortunate that structured concurrency ended up being a preview feature in 21. I agree that it's a great addition but man it'd be nice if it made the LTS.

As it stands, probably won't be heavily used until Java 25.

Congrats to you and the team on this huge milestone!

Really looking forward to taking advantage of these things (transparently and automatically!) in ZIO/Scala... which I think shows the true power of the JVM-as-platform approach you're taking!

1) dependencies need to be upgraded. for example, not all versions of Gradle support all Java versions. So you need to upgrade Gradle to upgrade Java.

2) other things are deemed to have higher priority.

3) people are satisfied with existing features and don't want to spend energy to upgrade to something that doesn't provide immediate value.

4) folks aren't educated on what the benefit of switching would be so why would it be prioritized? This is a case of "they don't know what they don't know".

I work on a team using Java 8 daily. It's fine. It's got things I wish it didn't (no null in switch statements for example) but I don't care about that so much that I'm going to go through the pain of upgrading 7-9 services in the mono repo, their dependencies, and then test them all to be on a new version of Java.

This is a niche case, but I spent months trying to upgrade one of our services from one LTS version to the next (I forget which). We encountered a weird bug where services running on the latest JRE would mysteriously corrupt fields when deserializing thrift messages, but only after running for a little while.

After an enormously unpleasant debugging cycle, we realized that the JIT compiler was incorrectly eliminating a call to System::arrayCopy, which meant that some fields were left uninitialized. But only when JIT compiled, non-optimized code ran fine.

This left us with three possible upgrade paths:

* Upgrade thrift to a newer version and hope that JIT compilation works well on it. But this is a nightmare since A) thrift is no longer supported, and B) new versions of thrift are not backwards compatible so you have to bump a lot of dependent libraries and update code for a bunch of API changes (in a LARGE number of services in our monorepo...). With no guarantee that the new version would fix the problem.

* File a bug report and wait for a minor version fix to address the issue.

* Skip this LTS release and hope the JIT bug is fixed in the next one.

* Disable JIT compilation for the offending functions and hope the performance hit is negligible.

I ultimately left the company before the fix was made, but I think we were leaning towards the last option (hopefully filing a bug report, too...).

There's no way this is the normal reason companies don't bump JRE versions as soon as they come out, but it's happened at least once. :-)

In general there's probably some decent (if misguided) bias towards "things are working fine on the current version, why risk some unexpected issues if we upgrade?"

The services I work on pump the entire business revenue from start to finish. A few nice to haves for devs aren't any where close in the risk calculation if something breaks

The bigger the project, the more painful the upgrade. Package systems are convenient to avoid reinventing the wheel, until you have to upgrade any piece of it. Then you're stuck trying to figure out which versions of each package go together.

If Package A won't run on JDK 17 your entire project is stuck on JDK 11. If Package B is upgraded but has conflicts with Package A, you have to dig through old versions until you find one that works -- and you don't get upgrades.

The more games somebody has played with reflection, undocumented features, deprecations, etc. the more likely you are to have a conflict. And since package managers encourage you to depend on somebody else's code, you end up depending on everybody else's code.

The smaller and greener the project is the more likely it is you can just pull the latest versions and be happy about it. A project that was written when Java 8 was current, and continued to develop, is going to be a nightmare.

Other workplaces have more long term supported systems, with more complex requirements, and more SLAs and guarantees to fulfil.

For an example, my team owns a dozen services and they have hundreds of direct and transient dependencies. Of those, maybe a dozen or two to need work to support the new version but that's a dozen different teams that have to put the work on their roadmap and prioritize it. When the entitlement is 'devs want to use shiny feature X with hard to quantify productivity benefit' it's difficult to prioritize. When there's an efficiency benefit then things move fast because a 10% efficiency improvement means 10% lower server costs and that's easy math.

On topic of upgrades, here are a couple of tricks I've learned throughout the years which make the upgrade process easier.

1. Use Maven 2. Use BOMs to manage related dependencies 3. No lombok

From an API perpective, you can always use reflection to cheat past the option to create virtual threads in pre-21 (without previews) java bytecode, but you need to do more to your code than just flip the switch to support virtual threads.

A virtual thread thread pool by definition is unbound. If you're binding data to a thread (eg. Thread locals, you now have a seemingly unbound list of threads that is now effectively a memory leak). I bumped into that one a few months ago with Netty that has a per thread cache for some things (thankfully you can turn off that cache). It was creating a significantly large waste of RAM that slowed down the application alone.

The other big one is as I mentioned the synchronized limitation. If you assume naively that anything can run in a virtual thread without worries, you're opening yourself up to deadlocks or at least significantly low performance code if you're relying on libraries/code that are synchronized using java monitors.

There may be more examples of gotchas, but these two are the most notable examples I have right now.

I believe, e.g. ZIO 2.next is doing something like this, dynamically deciding whether running something async or just doing the blocking thing depending on the availability of VThreads... but of course that's Scala, so YMMV.

Without a way to trampoline computation (or transform code appropriately) it's probably impractical to do anything like that.

(And of course, still many caveats as the sibling post points out.)

mrjars are a terrible idea, because libraries are very rarely a single jar, and require dependencies. Often that dependency set is different depending on the runtime version because of backports of newer Java APIs. So either you don't care and make your consumers use proguard to remove the unnecessary backports, or you create a Maven package with variants for each runtime version, which 99% of your downstream will end up using anyway.

It probably depends on the language you're using. Pattern matching is awesome in Erlang and Elixir. In most other languages it ranges from "nice" to "bleh".

When available, I pretty much always use pattern matching. It tends to shorten code while not reducing clarity (often increasing it) which means fewer opportunities for errors to creep in. Statically typed languages that can detect incomplete case handling also reduces the chances for some errors (as long as you don't make a catch-all case) but also helps when you change something so that a new case is needed. It also tends to shift the code to the left, reducing the indentation. So shorter, clearer, less unnecessary indentation. Generally a positive.

In languages that have strong support for pattern matching, whether it be on values or types, I find myself reaching for it instead of conditionals. It's all about the explicitness for me. You have to list out all the cases you care about, so there's no room for ambiguity. Plus, the compiler will usually warn you if you've missed a case, which is like a built-in bug catcher. It's also great for working with immutable data, less state to worry about. And let's talk about readability; the code basically documents itself because you can see the shape of the data right in front of you. You can even destructure data on the fly, pulling out exactly what you need. If you're using a statically-typed language, pattern matching adds an extra layer of type safety. And, not to forget, it nudges you toward a more functional style of coding, which I find leads to cleaner, more modular code. So yeah, I reach for pattern matching quite a bit; it often feels like the right tool for the job.

I think that you can replace almost any If else with pattern matching. Pattern matching makes type checks easier, which if you are really heavily using types through your program, makes pattern matching even better.

Pattern matching is what makes sum types ergonomic enough to be used. Many a Java design doesn't use said interface-based sum types because it's so cumbersome to use them. But whena language has pattern matching, then suddenly designing with sum types in mind is done a lot, and therefore you see examples of good pattern matching everywhere.

When I teach Scala, a very high percentage of the teaching time is ultimately down to re-introducing how to design business domains, because seasoned devs just reach for large classes with a million optional fields, which not only can represent valid systems states, but thousands of invalid ones.

One example for you: anytime you needed to use the "Visitor pattern" to do a transformation from one representation to another - you don't need it now. Sealed classes and pattern matching will be more succinct and easier to reason about.

Patterns are somewhat nice to have, but for me they’re difficult to read, and not because my brain isn’t used to them. The simple identifier instanceof is about all I’ll use _most_ of the time. Otherwise, yes they are more concise, but lose too much information in the process.

I’d rather see a boatload load of other features before patterns. I’ve been experimenting with project manifold[1]. _That_ is the path Java sb on. Just my take.

1. https://github.com/manifold-systems/manifold

In Python you can terminate a for loop with else, which will be run whenever the loop runs to the end without breaking

> We recently added pattern matching to Dart [1]

I've been using that and I love it, in general... but can I ask you why do we need to name a variable in a pattern like this:

    switch (p) {
      Person(name: var name) => ...
    }

That's the only thing that feels a bit annoying as you have to rename the variable... In Java, this would be something like:

    Person(var name) -> ...

EDIT: I guess it's to support `Person(name: 'literal')` matches.

> Dart doesn't have symbols

That's weird, as I actually use sometimes `#sym` (which has type `Symbol`)??

    print((#sym).runtimeType);

This prints `Symbol` :)

I know you know Dart in and out, but could you explain why this is not actually a symbol in the way Ruby symbols are?

You'll still have the structured concurrency calls but that's much better than pure callback hell.

They won't abandon async callback based code.

VT have too much memory overhead to be equivalent.

Currently virtual threads aren't a good match if you have a CPU heavy workload. The scheduler isn't fair and if your code doesn't enter into any blocking code it won't be unmounted from the carrier thread.

> Either of those severely limits the scalability

you can avoid both issues by using 20yo executorservice.

You could easily have a million threads if you use multi-kb stacks. Million times multi-kb means multi-gb, that's still 3-4 orders of magnitude less than big memory servers/VMs. (and 1 order of magnitude less than a normal laptop)

What do you mean by using a file handle, is this a Windows platform thing? On *ix, threads don't use up file descriptors (but you can still have a million fd's at least on linux for other stuff if you want).

I guess? I found them under the API diff linked as "miscellaneous new features".

I wonder if that's "not interesting" or "we already fixed this another way"

Scala is just too complex, the tooling too slow, and the community had way too many breaking changes.

It may be my specific setup. But on a 1440p display, 125% OS scale, I'm seeing more white left/right than actual content in the middle. It is also wrapping the code making it difficult to read.

Completely readable at 100% width though.

You can still use connection pool + platform threads. Or executor with virtual threads and semaphores or blocking queues. It’s mostly a concern for someone who implements a connection pool, for most devs it’s gonna be the same config option of max connection, that you need to pay attention to.

Any modern web app already has multiple instances of the app querying a db, so you have to keep a tally of total connection number either way.

From my perspective they're not entirely equivalent. The async variant seems to be batching getImages and saveImages, while the sync variant gets and saves each image individually, sequentially.