5 ms·

At one time, the JVM had superior configurability - many more runtime options for aggressive garbage collection, profiling, optimization, and debugging. But ma

• KirinDave 10y ago
  > At one time, the JVM had superior configurability - many more runtime options for aggressive garbage collection, profiling, optimization, and debugging. I'm not sure that this actually implies it was a more robust and production ready system. The JVM seems to be on a similar path of reducing somewhat how much tuning is expected of operators. Certainly we do less of it now on Java 8 (although some of the defaults it sets are truly boneheaded).
• alkonaut 10y ago
  The JVM initially targeted more diverse systems than the CLR (desktop only) so perhaps the JVM needed more configuration options. As far as I understand it, it was a design goal for the CLR to not require those configuration options. In fact, a lot of the design of both the CLR and C# can be easily traced to various shortcomings and pain points of Java (type erasure, value types, versioned modules, exceptions in method signatures etc).
• didibus 10y ago
  The JVM is still a more performant VM. And it does still have a lot more options for varying use cases with a big selection of GCs as well as custom VMs that let's you do real time programming. But as others pointed out, Android is not built on the JVM, but on Java. Java != JVM. And the CLR is a pretty great VM too. It's performance isn't as great as the JVM, but it's darn close, while also offering a lot of ease of use over the JVM.