4 ms·
Older code still runs in newer CLR vms -- which is the important part. This translates to "compatible, except in the case most people would and should not care
by batista 15y ago
Older code still runs in newer CLR vms -- which is the important part.
This translates to "compatible, except in the case most people would and should not care about" (running newer code in older vms).
This is far better than SUN's idea of Java forever keeping compatibility with old VMs with makes the language stagnate.
- __float 15y agoIn fact, depending on the language features you use, it may even be possible to compile down to an older CLR version, as the new language features are often simply syntactic sugar for some code generation that happens behind the scenes.
- bunderbunder 15y agoThat's exactly what's happening. All versions of .NET since version 2.0 are primarily library updates. They can all safely run on the same CLR, and there haven't had to be any changes to the CLR to enable new language features. A computer really only needs to have a second version of the CLR installed in order to run code that targets .NET 1.x
- sreque 15y agoThis isn't true. .NET 4.0 and on use a different runtime than 2.0, 3.0, and 3.5.
- bunderbunder 15y agoI stand corrected. Thanks.
- antrix 15y ago> (running newer code in older vms). That's pretty much how Java works too. In general, you can't take code compiled with a newer version and run it on an older VM. You will get class version mismatch errors.. they update the class version every time there's an incompatible change, such as when 'enum' became a keyword. The compatibility that Sun, err.. Oracle, strives for is to be able to mix code compiled with old & new versions without issues.