24. 受控執行環境
對[C#/IL碼/CLR]和[Java/字節碼/JVM]進行比較是不可避免的也是正當的。我想，最好的辦法是首先搞清楚為什麼會創造出這些技術來。
用C和C++寫程序，一般是把源代碼編譯成匯編語言代碼，它只能運行在特定的處理器和特定的操作系統上。編譯器需要知道目標處理器，因為不同的處理器指令集不同。編譯器也要知道目標操作系統，因為不同的操作系統對諸如如何執行工作以及怎樣實現象內存分配這些基本的C/C++的概念不同。C/C++這種模型獲得了巨大的成功（你所使用的大多數軟件可能都是這樣編譯的），但也有其局限性：
l 程序無豐富的接口以和其它程序進行交互（微軟的COM就是為了克服這個限制而創建的）
l 程序不能以跨平台的形式分發
l 不能把程序限制執行在一個安全操作的沙箱裡
為了解決這些問題，Java采用了Smalltalk采用過的方式，即編譯成字節碼，運行在虛擬機裡。在被編譯前，字節碼維持程序的基本結構。這就使得Java程序和其它程序進行各種交互成為可能。字節碼也是機器中立的，這也意味著同樣的class文件可以運行於不同的平台。最後，Java語言沒有顯式的內存操作（通過指針）的事實使得它很適合於編寫“沙箱程序”。
最初的虛擬機利用解釋器來把字節碼指令流轉換為機器碼。但是這個過程慢得可怕以致於對於那些關注性能的程序員來說，從來都沒有吸引力。如今，絕大多數JVM都利用JIT編譯器，基本編譯成機器碼—在進入類框架的范圍之前和方法體執行之前。在它運行前，還有可能將Java程序轉換為匯編語言，可以避免啟動時間和即時編譯的內存負擔。和編譯Visual C++程序相比，這個過程並不需要移去程序對運行時的依賴。Java運行時（這個術語隱藏在術語Java虛擬機下之下）將處理程序執行的很多至關重要的方面，比如垃圾收集和安全管理。運行時也被認為是受控執行環境。
盡管術語有點含糊不清，盡管從不用解釋器，但.NET基本模型也是使用如上所述方式。.NET的重要的改進將來自於IL自身的設計的改進。Java可以匹敵的唯一方式是修改字節碼規范以達到嚴格的兼容。我不想討論這些改進的細節，這應該留給那些極個別的既了解字節碼也了解IL碼的開發人員去討論。99%的象我這樣的開發人員不打算去研究IL代碼規范，這兒列出了一些意欲改進字節碼的IL設計決策：
l 提供更好的類型中立（有助於實現模板）；
l 提供更好的語言中立；
l 執行前永遠都編譯成匯編語言，從不解釋；
l 能夠向類、方法等加入附加的聲明性信息。參見15.特性；
目前，CLR還提供多操作系統支持，而且在其它領域還提供了對JVM的更好的互用性的支持。參見26.互用性。
