There are certain applications when it's far from an unneeded dependency. Namely building applications that are extensible by third parties, JVM allows very sim

There are certain applications when it's far from an unneeded dependency. Namely building applications that are extensible by third parties, JVM allows very simple runtime class-loading and has the class loader hierarchy to make this good. If you want to build a plugin system in most compiled languages you are stuck with either dynamic linking which is unrestrained and much more likely to cause whole program failure or IPC, which imposes overhead. Then you have portable applications. If I want to run on many architectures and platforms the JVM allows me to do this easily, no need to worry about cross compilation or even multiple binary distributions. So yeah. Is it always necessary if you are always going to target the same platform as your dev environment and never load code dynamically? Probably not. Is the tradeoff (higher memory usage) generally worth it? I think so. Not for all cases, for these I do think you have to go with a compiled language with better memory usage characteristics but that is about it tbh. Previously the JVM also sort of sucked at latency sensitive workloads unless you were very careful not to upset the garbage collector. This is now a non-issue. ZGC and Shenandoah outclass the best latency optimised collectors in languages like Golang. So really that only downside remaining is memory overhead, I don't actually think that one can be eliminated - it's likely to remain the "can I use JVM for this or not" lynchpin for the foreseeable future. (ignoring things like GraalVM native images because I don't know enough about them to speculate on if it can substantially lower memory usage)