7 ms·
Can anyone compare the JVM's technical merits with Microsoft's CLR? I always hear that the JVM compared to advanced alien technology, with its millions of engin
by mr_overalls 8y ago
Can anyone compare the JVM's technical merits with Microsoft's CLR? I always hear that the JVM compared to advanced alien technology, with its millions of engineer-hours, but not so much glowing praise about the CLR.
With Oracle remaining evil and Microsoft making waves in open source these days, I wonder how likely it is, for example, that a Big Data ecosystem like Hadoop/Spark/etc. could evolve around C# and .NET.
- Scarbutt 8y agoC# and .NET still have a long way to go to be considered mature enough for serious big projects in linux, linux being the key here.
- GordonS 8y agoErm, C# has been available via Mono for 14 years!
- severino 8y ago> Oracle remaining evil and Microsoft making waves in open source these days That's just PR. But real projects need sound technical motivations for making such a move.
- maxxxxx 8y ago"With Oracle remaining evil and Microsoft making waves in open source these days," I work with .NET and generally like it but .NET is still far, far away from the openness of Java. MS has open sourced a lot of stuff but it's still controlled by them. I also have my doubts for how long MS will sustain the move to open source. They have a long history of abandoning stuff like this after a few years and going back to business as usual.
- mgkimsal 8y ago> They have a long history of abandoning stuff like this after a few years and going back to business as usual. They also had a long history under gates, then ballmer. It may be that under nadella, these sorts of moves are (or are becoming) the new 'business as usual'.
- pjmlp 8y agoEarlier this year I had to port a couple of small apps from .NET to Java, because the customer wasn't able to port all the necessary dependencies to .NET Core, while the existing Java counterparts from the same vendors had 1:1 feature parity with .NET Framework.
- vertex-four 8y agoThere's .Net Core (standalone, open source, cross-platform), the .Net Framework (closed source, Windows-only), Mono (open source, cross-platform, implements significant chunks of .Net Framework standard libraries), and the UWP runtime (closed source, part of Windows). At least three of those four implement completely separate VMs. Which is important to you?
- randomsearch 8y agoCan confirm JVM is the most impressive software I’ve ever hacked. Some of the GC algorithm code is insane, same for the JIT.
- bsaul 8y agoDo you have any link to some source code that shows this insanity ?
- _old_dude_ 8y agohttp://hg.openjdk.java.net/jdk/jdk/file/65e65d5905bc/src/hotspot/share/interpreter/interpreterRuntime.cpp#l1065 http://hg.openjdk.java.net/jdk/jdk/file/65e65d5905bc/src/hot... The VM interpreter is generated from assembly code snippets that calls this class when something complex need to be done. Hotspot is written in C++ and objects shared by Java and the VM can be seen either in Java or in C++ because they have a Java header and a C++ header. Classloading is done lazily in Java so you can not preload classes until the first time you see it. If you see a non loaded class in the JITed code, you have to jump back into the interpreter and re-generate the assembly code later. OSR stands for on stack replacement which means that while you are interpreting a loop, you decide to JIT its body. Biased locking is a way to implement monitor/lock if those locks are used only by one thread, you biased the lock to that thread, which is slightly more efficient. The stack contains stack frames of different kinds Java, C, adapters (assembly stubs between the 2 JITs and the interpreter which obviously doesn't use the same calling convention) but you have a common way to iterate on them. All Hotspot GCs are generational so you have to hold every pointers (Java reference) into Handles (box known by the GC) because the GC may decide to move the objects while the C++ code hold them. Obviously, all this mechanisms make sense but managing the complexity of all of them working together is insane.
- randomsearch 8y agoThanks for posting that _old_dude_ - I was going to post similar things. I'd also throw in the Shenandoah GC from Red Hat. I don't remember the details anymore, but I remember thinking it was an amazing bit of code: https://www.youtube.com/watch?v=N0JTvyCxiv8 https://www.youtube.com/watch?v=N0JTvyCxiv8
- gecko 8y agoThey’re honestly not quite miscible. I know that, when .NET came out, everyone responded with “haha they copied Java,” but the truth is that they make a pile of very different technical trade-offs. The CLR has explicit stack allocation, the JVM does not. The JVM is genuinely a JIT, the CLR is really all about AOT. The CLR has full support for low-level code (pointers and such), while the JVM does not. The JVM and its class library has been cross-platform from day one, the CLR in a meaningful sense has not. The CLR has a really simple FFI, the JVM traditionally has not. The CLR has reified generics, the JVM does not. The JVM has a much more advanced GC, the CLR’s use of value types and things like Span<> means that such an advanced GC is (at least arguably) not necessary, and so on. I really love the CLR, and I think it’s just as much “alien technology” as the JVM. I suspect the lack of love for it likely has more to do with the official versions being Windows-only than anything else. But I think it’s also just true that, while they both fill the same niche in a grand way (they’re both high-level VMs), their details are sufficiently different that a direct comparison doesn’t honestly make a ton of sense.
- pvg 8y agothat a direct comparison doesn’t honestly make a ton of sense. I think a comparison of them as products/platforms and the way the combination of technical and business decisions have influenced their trajectories is still interesting and instructive. Microsoft's very belated recognition that they won't be able to extend their OS dominance to all things server also means they've mostly squandered the technical advantages of the CLR. Oracle can catch up with the missing bits technologically (and they are doing just that) whereas it's by now really hard for the CLR to catch up in marketshare. Which is a pity.
- mwcampbell 8y agoSince you seem to have a strong understanding of both JVM and CLR, do you know if it would be feasible to translate CIL bytecode to JVM bytecode without having terrible performance in the translated code? In particular, I wonder if Xamarin.Android could do this (of course, in that case the JVM bytecode would be further translated to Dex), to provide an alternative to the current hairy interop situation with JNI and two GCs.
- pjmlp 8y agoOracle is as we all know, but at least they kept improving Java and sponsored the work being done at Sun Labs, turning it into Graal and Substrate. If tomorrow they really completely loose interest in Java and let everyone go, are the same Java companies that let Sun fall now going to rescue Java and keep developing OpenJDK?
- paidleaf 8y ago> With Oracle remaining evil and Microsoft making waves in open source these days MSFT is not making as big a wave as you'd think. A lot of the hype is MSFT PR machine running rampant. I use Visual Studio/.Net on windows and only on windows because it's what many corporations use. But I use linux and bsd + vim/etc at home. A lot of MSFT software may be going open source but they also bring with it "spying telemetry" and I suspect eventually ads. It surprises me how little outrage there is over MSFT spying as there is with facebook. Windows is literally a keylogger and scanner all in one. It's pretty much spyware.