They didn't write the runtime, they just modified a (relatively) small piece of it. From the article:

> JetBrains forked the OpenJDK project in order to facilitate better control over how the IDEs looked on Macs a well as other HiDPI screens; JetBrains Runtime was born and we bundled it with our IDEs from 2014.

> There are many facets of the runtime, and we do not know every little crevice of it, rather we focus on the part of the code that handles the rendering of UI on screens.

This isn't it's own runtime. It's a modified JDK and when you're one of the largest pieces of GUI software in Java, you're obviously going to have things you want to change in it.

They've created a huge platform. They're going to have needs that aren't met in a pre-packaged thing.

VSCode avoided using any frontend frameworks, does that mean they made a wrong engineering choice?

Here's the problem: they selected Java many, many years ago back when Apple shipped Java as part of Mac OS X. I believe they're based on IntelliJ and presumably have added a considerable amount of their own code over the last 20 years. They certainly didn't know that the Oracle acquisition would lead to Apple removing a not unpopular feature due to legal risks.

With a large cross-platform codebase like that, Java is an understandable choice and at any point the cost of switching would be greater than the cost of fixing the current issue.

Ah, yes. The classic let's rewrite everything from first principles instead of using a proven, state-of-the-art runtime for which we just to reimplement font rendering.

Not necessarily. It could be that even though they have to rewrite some of the runtime it's still the right tool for the job.

This was my main thought. Maybe all that effort expended on managing the runtime could be aggregated into a unified effort in a more cohesive (to your goals) language.