7 ms·
Differences Between the CLR and the JVM
- sk5t 11y agoThis is a weird collection of observations about C# and CLR intermingled without apparent rhyme or reason, although the author seems to understand that they are not interchangeable...
- astral303 11y agoIsn't the JVM's notion of packages and class loaders effectively the same thing as CLR namespaces?
- sk5t 11y agoThe most analogous thing to a JVM classloader in CLR is the AppDomain. Java packages and .NET namespaces are largely similar (the CLR supports a superset of naming concepts like explicit implementation).
- recursive 11y ago> C# has partial classes > C# can have multiple classes in a single file Perhaps there are others, but these have nothing to do with the CLR. A JVM language could easily have these features if the language supported it.
- draw_down 11y agoRight, that's why it says "C# has", not "CLR has".
- bmay 11y agoIt says both - those "C# has" bullets are under a "CLR has…" header.
- RubyPinch 11y ago> It also bleeds into differences between C# and Java whose features often include compiler-level-only features that the underlying VirtualMachine is not cognizant of. aka "if the list says C#, its because it applies to C# and not CLR"
- shrewduser 11y agoit still confuses the issue as the title says it's a CLR vs JVM comparison, there are dozens of languages on each so i don't see why they're bringing C# vs java into it.
- groovy2shoes 11y agoCLR also supports proper tail calls, where the JVM does not (yet).
- mastazi 11y agoYes, surprisingly this feature, which is very important (see how Scala had to find a way around it [1]), has been overlooked. To me, it seems like a list put together in a non-systematic way. [1] https://medium.com/binary-dreams/from-java-to-scala-tail-recursion-a6acdd71a94d#.fs6lythj2 https://medium.com/binary-dreams/from-java-to-scala-tail-rec...
- MichaelGG 11y agoCLR .tail prefix is only a hint and not guaranteed. And traditionally it's had a ton of restrictions and limitations and was slow enough that F# stopped emitting it except when needed. (A lot of code ends up tail call optimizable, even if not recursive or designed that way.) Is rather have the JVM's compressed pointers and escape analysis.
- jdmichal 11y agoThough it's important to note that it's only a suggestion for the CLR runtime. For instance, in .NET v2 (which as an engine also covers v3) it was rare for tail call optimization to trigger in 64-bit mode. They finally fixed this in .NET v4 to make F# viable. https://blogs.msdn.microsoft.com/clrcodegeneration/2009/05/11/tail-call-improvements-in-net-framework-4/ https://blogs.msdn.microsoft.com/clrcodegeneration/2009/05/1...
- ryanlm 11y agoIn the end it seems like CLR is superior to the JVM based on these assertions.
- Mikeb85 11y agoExcept for the fact the JVM has far superior performance...
- sremani 11y agoI understand JVM is battle tested on Linux, *BSD, where CLR would have to catch up, but are there any technical reasons say JVM perfs better than CLR on windows.
- richard_todd 11y agoJVM optimizes and reoptimizes as your code runs, so that "hot spots" run very quickly. Last I heard, CLR still doesn't do this... it JITs once only.
- MikeHolman 11y agoThis multitiered approach does not necessarily make the end result faster. It is in vogue to do this, and for startup performance having a baseline JIT can be beneficial, but for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time.
- jdmichal 11y ago> ... for workload throughput adding another tier isn't going to do much unless you have some concrete optimizations you are going to run that you decided against due to cost of compile time. Isn't this statement pretty much the entirety of the reason to implement multi-tiered JITs? Do a fast JIT with few optimizations to get out of interpreted mode. Then do a slow JIT after you've collected enough statistics to make good optimization decisions.
- jcranmer 11y agoJVM doesn't really have a notion of virtual versus non-virtual methods, it's a matter of which calling opcode you use (invokevirtual versus invokespecial). It's also sort of missing the big difference... the JVM is generally superior in performance to the CLR, having a better JIT and better GC performance.
- bunderbunder 11y agoI'm not sure I'd consider performance a big difference. Their performance is generally very close, and if you're in a situation to care enough about performance to split hairs then you really shouldn't be using a managed platform in the first place. The _real_ big difference is that Java has an enormous open source ecosystem, whereas much of what .NET has is ports or clones of successful Java projects. That said, I think .NET's probably the better choice for a lot of line-of-business applications simply because the tooling allows for very rapid development of that sort of stuff, and not having easy access to Hadoop or Akka really isn't much of a handicap when you're mostly just banging out a mess of business rules.
- jcranmer 11y agoThe title implies that it's comparing the runtime engines, and the performance is absolutely a major selling point of any such comparison, even if the practical effect of any difference is negligible. Ultimately, the comparison claims to be between the CLR and the JVM while it's more like between C# and Java, given how it only covers fairly superficial features at the front-end level and not what can and can't be done in VM code, let alone how different VM architectures can have major impacts on code design, etc.
- bunderbunder 11y agoI think the reason for this particular list is that it's from the standpoint of a programming language implementation team, and one that's currently working on targeting a 2nd platform. Given that, it reads as a list of what the VM can do for you and what you'll need to do yourself in the compiler.
- 13of40 11y agoSplitting hairs, but the CLR is just one implementation of the Virtual Execution System (VES). The spec for all of this behavior is about the VES.
- pavanky 11y agoThis is not "differences between CLR and JVM", but more of "why I think CLR is better than JVM". Anyway the biggest issue I have seen in my line of work (building GPU software, and people want GPU acceleration from their language of choice) is that JVM does not provide a way to handle external resources properly. Calling garbage collection does not guarantee that the out of scope objects will be finalized. This results in either code that uses up a lot of memory or code that is very un-java like. Yes I know try with resources exist, but the problem still exists for any temporary variables you create within the block. If anyone here has a better solution, I am all ears.
- sk5t 11y agoI suggest never to call the garbage collector with the expectation that anything in particular will happen--not in CLR and not in the JVM. Also, do not use finalizers for this! JNI and P/Invoke are not really that different except that P/Invoke is a lot easier to implement. But CLR does not know how to cleanup unmanaged resources automagically. edit: I removed my notes about "try with resource" and AutoCloseable
- pavanky 11y agoWell the only solution remaining is writing C like code, where users have to allocate and free memory manually which is not a solution if you ask me.
- kinghajj 11y agoMay I interest you in Rust? https://www.rust-lang.org/ https://www.rust-lang.org/
- pavanky 11y agoWe already have a wrapper for rust[1] and C++, fortran, python and various other languages[2]. I was talking about people not wanting to move away from their language of choice which results in us having to try and support them as well. [1] https://github.com/arrayfire/arrayfire-rust https://github.com/arrayfire/arrayfire-rust [2] https://github.com/arrayfire https://github.com/arrayfire
- derefr 11y agoHaving recently been tinkering with the Objective-C Runtime (writing a bridge to another language), I think it'd be interesting to extend the comparison there as well. Actually, a more systemic review of what all the various various runtime platforms are capable of, apart from any particular languages implemented on those platforms, would be excellent reading. (For just one example, I'd really like to see a comparison of the availability+overhead of various concurrency primitives in the runtimes of the JVM vs. Erlang's BEAM, vs. Obj-C's libdispatch, etc. The languages on each platform emphasize concurrency differently, but often at the VM level things are more similar than people think.)
- nicobn 11y agoThere's nothing stopping you from declaring additional static classes inside a class in Java. You can definitely declare multiple classes in a single file.
- jdmichal 11y agoThat's not even close to the same thing. C# allows declaration of types within other types, but it also allows declaration of multiple top-level types within a single compilation unit. And with partial classes, it also allows declaration of a single type across multiple compilation units.
- douche 11y agoIt's a small thing, but between this and the properties syntax sugar (avoiding having to hand-write all the SetX GetX methods that litter Java code), it adds up for cruddy stuff where you end up needing to define a bunch of POCOs, for instance with EF or JSON REST APIs.
- nicobn 11y agoThe point that was made is that multiple (static) classes cannot be declared in the same file, which is 100% false. I'm not arguing that C# is functionally equivalent to Java. There was no mention of "compilation unit" or "partial classes", which are a completely different subject. It doesn't matter whether the additional classes defined in the file are top level or not, they're still classes that can be used independently.
- jdmichal 11y agoYou are being disingenuous. "File" is layman-speak for "compilation unit", so it is not a "completely different subject". You cannot declare multiple top-level types in a single compilation unit in Java. Yes, you can create static types within another type. However, those are not top-level types; they are scoped within the type they are declared in. Let's just put it this way. Would a Java programmer, by way of normal operation, implement a project with a few Java files, each of which contains a type with several static types internal to it, and where those internal static types are in fact the main types of the program? If they wouldn't, then there is no equivalency, because this is something you see in C# code bases all the time.
- deleted 11y ago[deleted]
- noblethrasher 11y agoComparing the CLR and JVMs in terms of anything other than features is bizarre. This is because the CLR/VES and JVMs are both examples of the actual important thing about general purpose computing: Computers can simulate anything, including “better” computers (that’s what Universal Turing Machine means). But, when using one computer to simulate a “better” one, you’re always going to be giving up some raw performance that you don’t care about in order to get some features that you desperately want (after all, you are going through the enormous trouble of designing/implementing/running a simulation of another freaking general purpose computer). Now, “better” can mean lots of things: • The simulated computer has unbounded memory • The simulated computer doesn’t (under|over)flow on arithmetic • There are more people on the market that know how to program the simulated computer • The simulated computer is more widely deployed • The simulated computer is more secure/reliable • The simulated computer is not controlled by a single faction • The simulated computer readily runs programs encoded in your favorite language • The simulated computer can easily simulate a computer that runs programs encoded in your favorite language (the subject of the article) So, simulated computer A is strictly better than simulated computer B only in the following cases: • A has the features that you want and B does not • A and B both have the features that you want, but the former traded away significantly less raw performance than did the latter. Since the CLR and JVMs are so similar with respect to performance, you should only compare them in terms of the features that you want. Personally, I think that MS was wise to go for more features at the expense of some performance since that’s really the whole point of a VM. But, unfortunately for them (and fans of CLR/VES/C#/VB/F#) they (historically) could not compete on features that quite a few people really care about (e.g. not perceived to be controlled by a single company, runs well on Linux, marketable in the Valley, etc.)
- known 11y agoWhat's the size of a typical CLR and JVM?