Yes well, I assume we all understand there are two separate compilation/translation steps at work here (well perhaps not Massimo). The major difference is that .NET was not designed to be consumed by an interpreter or any kind of adaptive recompilation. So while the JVM has the benefit of a mature and awesome HotSpot adaptive recompiler kicking in to save the day, the CLR AOT compiler does its thing exactly once - no more and no less. This makes the two compilation steps on .NET more important than with the JVM.
The .NET folks did this, as I understand it, out of simplicity. For example, the CIL emitter (due to non-virtual-by-default) does not have to worry about inlining (and rolling back optimizations) as is one of the major HotSpot boosters (due to Java's virtual-by-default). And it does offer some benefits, when you debug you can see the CIL assembly and know *exactly* what is taking place. As awesome as HotSpot is, it can also be a treacherous black box. Another difference is that .NET was never intended to fully replace native/non-managed code, but rather to inter-operate easily with it. You often call into non-managed code and you can have fun with pointers if you so choose (which probably explains why Mono has success on Linux where there's a culture of calling out to existing stuff). This is not all that different from the recent Android stack, where you often do the "heavy lifting" using the NDK (C) and the rest of the stuff with the SDK (Java). I think both are learning from each other though, it sounds like it from people going to the .NET symposium (Charles Nutter etc.) and that's great news regardless of whichever camp you belong to. I just happen to like elements from both. :) /Casper On 14 Sep., 22:03, Joshua Marinacci <jos...@marinacci.org> wrote: > I just read through the link you sent. Interesting stuff. > > Yes, it's true that the CLR (which is what they are talking about, not > C# the language, when referring to JIT stuff) was designed to be only > JITed not interpreted; whereas Java was originally designed for more > constrained devices (and 10 years earlier) and had interpreted VMs as > a design goal. However, I'm pretty sure JIT support was one of the > original design goals of Java as well, since JITs pre-date both the > JVM and the CLR. > > In any case, in their article they are still talking about runtime > dynamic optimizations, not static compilation down to machine code at > development time. I think the confusion here is about the word > 'compile'. Both the JVM and the CLR do Just In Time compilation, > where bytecode (not source code) is transformed into machine code at > *runtime*. What these iPhone projects are doing is turning source > code or bytecode into Objective C code *at development time* and > compiling that into machine code using standard native compilers. > These are totally different senses of the word 'compile'. Neither the > JVM nor the CLR had static compilation to machine code at development > time down a design goal. Both of them *do* still compile their source > into a virtual machine byte code, which is then interpreted or JITed > at runtime. > > The JVM and the CLR are actually quite similar and have similar design > goals. And they are part of the larger long term trend towards managed > environment programming. The days of statically compiling C code and > it's equivalents are quickly coming to an end, much as almost no one > writes assembly anymore. > > - J > > On Sep 14, 2009, at 11:11 AM, Casper Bang wrote: > > > > >> something that's there in order to speed up emulation > > > That should've said "something that's there in order to speed up > > interpretation". > > > Luckily you don't have take my word for it, I've digged this piece up > > for you by Bill Venners, Bruce Eckel and Anders Hejlsberg: > >http://www.artima.com/intv/choices.html > > > Joshua is also right of course, Java can be statically compiled too. > > But I did not claim Java could not be statically compiled, I said that > > C# was designed to always be compiled, Java was not. > > > /Casper --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
