5 ms·
What would be required to bring the CLR up to the JVM's legendary level of engineering?
by mr_overalls 10y ago
What would be required to bring the CLR up to the JVM's legendary level of engineering?
- riffraff 10y agoisn't the clr already there?
- KirinDave 10y agoIt's already there? The CLR is a well maintained and engineered system. Why do you believe otherwise?
- mr_overalls 10y agoAt one time, the JVM had superior configurability - many more runtime options for aggressive garbage collection, profiling, optimization, and debugging. But maybe you're right - it's been a few years since I made a looked at the comparison.
- 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 agoThe 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 agoThe 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.
- deleted 10y ago[deleted]