Windows
Native的c++應(yīng)用大量使用了DLL技術(shù)。"動態(tài)鏈接"這幾字指明了DLLs是如何工作的。對于常規(guī)的函數(shù)庫，鏈接器從中拷貝它需要的所有庫函數(shù)，并把確切的函數(shù)地址傳送給調(diào)用這些函數(shù)的程序。而對于DLLs，函數(shù)儲存在一個獨立的動態(tài)鏈接庫文件中。在創(chuàng)建Windows程序時，鏈接過程并不把DLLs文件鏈接到程序上。直到程
序運行并調(diào)用一個DLLs中的函數(shù)時，該程序才要求這個函數(shù)的地址。此時Windows才在DLLs中尋找被調(diào)用函數(shù)，并把它的地址傳送給調(diào)用程序。采用這種方法，DLLs達(dá)到了復(fù)用代碼的極限。
對于DLL,
關(guān)鍵一點是，所有run on windows
system 的程序可以共用同一個DLL庫，從而達(dá)到最大限度的代碼復(fù)用。并且，由于DLL并不拷貝它需要的所有庫函數(shù)
， 這樣的話Native的C++程序
executable image size 會比較小。
從modularity的角度，如果要在Java的應(yīng)用里尋找相對應(yīng)的DLL的概念，我們會自然地想到jar包。JAR包可以被
Class Loader動態(tài)裝載進(jìn)JVM,
不過要幾點區(qū)別需要說明的是：
第一、從本質(zhì)上來講，JAR包是存在于磁盤上的一些data而已(由JVM解釋執(zhí)行)，而DLL是executable
的image。
第二、Class
Data Sharing (CDS)作為一個新的feature,在Java5才被引入，其做法就是：把
system jar 文件打包成為"shared
archive"，這些"shared
archive"會作為memory-mapped
in文件存在，共享于不同的JVM
進(jìn)程間，以減少JVM的footprint,加快Java應(yīng)用的啟動時間。
值得一提的是：兩者都有所謂的HELL問題(JAR HELL vs DLL HELL)，新老版本的兼容問題始終讓人頭疼。
詳見解釋：
http://en.wikipedia.org/wiki/DLL_hell
http://en.wikipedia.org/wiki/JAR_hell#JAR_hell