潛心學習 技術強身

轉自：http://m.tkk7.com/Unmi/archive/2007/12/04/165035.html
一：要解決的問題

我們在嘗鮮 JDK1.5 的時候，相信不少人遇到過 Unsupported major.minor version 49.0 錯誤，當時定會茫然不知所措。因為剛開始那會兒，網上與此相關的中文資料還不多，現在好了，網上一找就知道是如何解決，大多會告訴你要使用 JDK 1.4 重新編譯。那么至于為什么，那個 major.minor 究竟為何物呢？這就是本篇來講的內容，以使未錯而先知。

我覺得我是比較幸運的，因為在遇到那個錯誤之前已研讀過《深入 Java 虛擬機》第二版，英文原書名為《Inside the Java Virtual Machine》( Second Edition)，看時已知曉 major.minor 藏匿于何處，但沒有切身體會，待到與 Unsupported major.minor version 49.0 真正會面試，正好是給我驗證了一個事實。

首先我們要對 Unsupported major.minor version 49.0 建立的直接感覺是：JDK1.5 編譯出來的類不能在 JVM 1.4 下運行，必須編譯成 JVM 1.4 下能運行的類。(當然，也許你用的還是 JVM 1.3 或 JVM 1.2，那么就要編譯成目標 JVM 能認可的類)。這也解決問題的方向。

二：major.minor 棲身于何處

何謂 major.minor，且又居身于何處呢？先感性認識并找到 major.minor 來。

寫一個 Java Hello World! 代碼，然后用 JDK 1.5 的編譯器編譯成，HelloWorld.java
用 JDK 1.5 的 javac -d .  HelloWorld.java 編譯出來的字節碼 HelloWorld.class 用 UltraEdit 打開來的內容如圖所示：



從上圖中我們看出來了什么是 major.minor version 了，它相當于一個軟件的主次版本號，只是在這里是標識的一個 Java Class 的主版本號和次版本號，同時我們看到 minor_version 為 0x0000，major_version 為 0x0031，轉換為十制數分別為0 和 49，即 major.minor 就是 49.0 了。

三：何謂 major.minor 以及何用

Class 文件的第 5-8 字節為 minor_version 和 major_version。Java class 文件格式可能會加入新特性。class 文件格式一旦發生變化，版本號也會隨之變化。對于 JVM 來說，版本號確定了特定的 class 文件格式，通常只有給定主版本號和一系列次版本號后，JVM 才能夠讀取 class 文件。如果 class 文件的版本號超出了 JVM 所能處理的有效范圍，JVM 將不會處理該 class 文件。

在 Sun 的 JDK 1.0.2 發布版中，JVM 實現支持從 45.0 到 45.3 的 class 文件格式。在所有 JDK 1.1 發布版中的 JVM 都能夠支持版本從 45.0 到 45.65535 的 class 文件格式。在 Sun 的 1.2 版本的 SDK 中，JVM 能夠支持從版本 45.0 到46.0 的 class 文件格式。

1.0 或 1.2 版本的編譯器能夠產生版本號為 45.3 的 class 文件。在 Sun 的 1.2 版本 SDK 中，Javac 編譯器默認產生版本號為 45.3  的 class 文件。但如果在 javac 命令行中指定了 -target 1.2 標志，1.2 版本的編譯器將產生版本號為 46.0 的 class 文件。1.0 或 1.1 版本的 JVM 上不能運行使用-target 1.2 標志所產生的 class 文件。

JVM 實現的 第二版中修改了對 class 文件主版本號和次版本號的解釋。對于第二版而言，class 文件的主版本號與 Java 平臺主發布版的版本號保持一致(例如：在 Java 2 平臺發布版上，主版本號從 45 升至 46)，次版本號與特定主平臺發布版的各個發布版相關。因此，盡管不同的 class 文件格式可以由不同的版本號表示，但版本號不一樣并不代表 class 文件格式不同。版本號不同的原因可能只是因為 class 文件由不同發布版本的 java 平臺產生，可能 class 文件的格式并沒有改變。

上面三段節選自《深入 Java 虛擬機》，啰嗦一堆，JDK 1.2 開啟了 Java 2 的時代，但那個年代仍然離我們很遠，我們當中很多少直接跳在 JDK 1.4 上的，我也差不多，只是項目要求不得不在一段時間里委屈在 JDK 1.3 上。不過大致我們可以得到的信息就是每個版本的 JDK 編譯器編譯出的 class 文件中都帶有一個版本號，不同的 JVM 能接受一個范圍 class 版本號，超出范圍則要出錯。不過一般都是能向后兼容的，知道 Sun 在做 Solaris 的一句口號嗎？保持對先前版本的 100% 二進制兼容性，這也是對客戶的投資保護。

四：其他確定 class 的 major.minor version 辦法

1）Eclipse 中查看
      Eclipse 3.3 加入的新特征，當某個類沒有關聯到源代碼，打開它會顯示比較詳細的類信息，當然還未到源碼級別了，看下圖是打開 2.0 spring.jar 中 ClasspathXmlApplicationContext.class 顯示的信息


2）命令 javap -verbose
       對于編譯出的 class 文件用 javap -verbose 能顯示出類的 major.minor 版本，見下圖：


3)  MANIFEST 文件
      把 class 打成的 JAR 包中都會有文件 META-INF\MANIFEST，這個文件一般會有編譯器的信息，下面列幾個包的 META-INF\MANIFEST 文件內容大家看看
      ·Velocity-1.5.jar 的 META-INFO\MANIFEST 部份內容
                  Manifest-Version: 1.0
                  Ant-Version: Apache Ant 1.7.0
                  Created-By: Apache Ant
                  Package: org.apache.velocity
                  Build-Jdk: 1.4.2_08
                  Extension-Name: velocity
            我們看到是用 ant 打包，構建用的JDK是 1.4.2_08，用 1.4 編譯的類在 1.4 JVM 中當然能運行。如果那人用 1.5 的 JDK 來編譯，然后用 JDK 1.4+ANT 來打包就太無聊了。
      ·2.0 spring.jar 的 META-INFO\MANIFEST 部份內容
                  Manifest-Version: 1.0
                  Ant-Version: Apache Ant 1.6.5
                  Created-By: 1.5.0_08-b03 (Sun Microsystems Inc.)
                  Implementation-Title: Spring Framework
           這下要注意啦，它是用的 JDK 1.5 來編譯的，那么它是否帶了 -target 1.4 或 -target 1.3 來編譯的呢？確實是的，可以查看類的二進制文件，這是最保險的。所在 spring-2.0.jar 也可以在 1.4 JVM 中加載執行。
      ·自已一個項目中用 ant 打的 jar 包的 META-INFO\MANIFEST
                  Manifest-Version: 1.0
                  Ant-Version: Apache Ant 1.7.0
                  Created-By: 1.4.2-b28 (Sun Microsystems Inc.)
            用的是 JDK 1.4 構建打包的。

第一第二種辦法能明確知道 major.minor version，而第三種方法應該也沒問題，但是碰到變態構建就難說了，比如誰把那個 META-INFO\MANIFEST 打包后換了也未可知。直接查看類的二進制文件的方法可以萬分保證，準確無誤，就是工具篡改我也認了。

五：編譯器比較及癥節之所在

現在不妨從 JDK 1.1 到 JDK 1.7 編譯器編譯出的 class 的默認 minor.major version 吧。（又走到 Sun 的網站上翻騰出我從來都沒用過的古董來）

JDK 編譯器版本	target 參數	十六進制 minor.major	十進制 minor.major
jdk1.1.8	不能帶 target 參數	00 03   00 2D	45.3
jdk1.2.2	不帶(默認為 -target 1.1)	00 03   00 2D	45.3
jdk1.2.2	-target 1.2	00 00   00 2E	46.0
jdk1.3.1_19	不帶(默認為 -target 1.1)	00 03   00 2D	45.3
jdk1.3.1_19	-target 1.3	00 00   00 2F	47.0
j2sdk1.4.2_10	不帶(默認為 -target 1.2)	00 00   00 2E	46.0
j2sdk1.4.2_10	-target 1.4	00 00   00 30	48.0
jdk1.5.0_11	不帶(默認為 -target 1.5)	00 00   00 31	49.0
jdk1.5.0_11	-target 1.4 -source 1.4	00 00   00 30	48.0
jdk1.6.0_01	不帶(默認為 -target 1.6)	00 00   00 32	50.0
jdk1.6.0_01	-target 1.5	00 00   00 31	49.0
jdk1.6.0_01	-target 1.4 -source 1.4	00 00   00 30	48.0
jdk1.7.0	不帶(默認為 -target 1.6)	00 00   00 32	50.0
jdk1.7.0	-target 1.7	00 00   00 33	51.0
jdk1.7.0	-target 1.4 -source 1.4	00 00   00 30	48.0
Apache Harmony 5.0M3	不帶(默認為 -target 1.2)	00 00   00 2E	46.0
Apache Harmony 5.0M3	-target 1.4	00 00   00 30	48.0

上面比較是 Windows 平臺下的 JDK 編譯器的情況，我們可以此作些總結：

1) -target 1.1 時 有次版本號，target 為 1.2 及以后都只用主版本號了，次版本號為 0
2) 從 1.1 到 1.4 語言差異比較小，所以 1.2 到 1.4 默認的 target 都不是自身相對應版本
3) 1.5 語法變動很大，所以直接默認 target 就是 1.5。也因為如此用 1.5 的 JDK 要生成目標為 1.4 的代碼，光有 -target 1.4 不夠，必須同時帶上 -source 1.4，指定源碼的兼容性，1.6/1.7 JDk 生成目標為 1.4 的代碼也如此。
4) 1.6 編譯器顯得較為激進，默認參數就為 -target 1.6。因為 1.6 和 1.5 的語法無差異，所以用 -target 1.5 時無需跟著 -source 1.5。
5) 注意 1.7 編譯的默認 target 為 1.6
6) 其他第三方的 JDK 生成的 Class 文件格式版本號同對應 Sun 版本 JDK
7) 最后一點最重要的，某個版本的 JVM 能接受 class 文件的最大主版本號不能超過對應 JDK 帶相應 target 參數編譯出來的 class 文件的版本號。

上面那句話有點長，一口氣讀過去不是很好理解，舉個例子：1.4 的 JVM 能接受最大的 class 文件的主版本號不能超過用 1.4 JDK 帶參數 -target 1.4 時編譯出的 class 文件的主版本號，也就是 48。

因為 1.5 JDK 編譯時默認 target 為 1.5，出來的字節碼 major.minor version 是 49.0，所以 1.4 的 JVM 是無法接受的，只有拋出錯誤。

那么又為什么從 1.1 到 1.2、從 1.2 到 1.3 或者從 1.3 到 1.4 的 JDK 升級不會發生 Unsupported major.minor version 的錯誤呢，那是因為 1.2/1.3/1.4 都保持了很好的二進制兼容性，看看 1.2/1.3/1.4 的默認 target 分別為 1.1/1.1/1.2 就知道了，也就是默認情況下1.4 JDK 編譯出的 class 文件在 JVM 1.2 下都能加載執行，何況于 JVM 1.3 呢？（當然要去除使用了新版本擴充的 API 的因素）

六：找到問題解決的方法

那么現在如果碰到這種問題該知道如何解決了吧，還會像我所見到有些兄弟那樣，去找個 1.4 的 JDK 下載安裝，然后用其重新編譯所有的代碼嗎？其實大可不必如此費神，我們一定還記得 javac 還有個 -target 參數，對啦，可以繼續使用 1.5 JDK，編譯時帶上參數 -target 1.4 -source 1.4 就 OK 啦，不過你一定要對哪些 API 是 1.5 JDK 加入進來的了如指掌，不能你的 class 文件拿到 JVM 1.4 下就會 method not found。目標 JVM 是 1.3 的話，編譯選項就用 -target 1.3 -source 1.3 了。

相應的如果使用 ant ，它的 javac 任務也可對應的選擇 target 和 source

<javac target="1.4" source="1.4" ............................/>

如果是在開發中，可以肯定的是現在真正算得上是 JAVA IDE 對于工程也都有編譯選項設置目標代碼的。例如 Eclipse 的項目屬性中的 Java Compiler 設置，如圖



自已設定編譯選項，你會看到選擇不同的 compiler compliance level 是，Generated class files compatibility 和 Source compatibility 也在變，你也可以手動調整那兩項，手動設置后你就不用很在乎用的什么版本的編譯器了，只要求他生成我們希望的字節碼就行了，再引申一下就是即使源代碼是用 VB 寫的，只要能編譯成 JVM 能執行的字節碼都不打緊。在其他的 IDE 也能找到相應的設置對話框的。

其他時候，你一定要知道當前的 JVM 是什么版本，能接受的字節碼主版本號是多少（可對照前面那個表）。獲息當前 JVM 版本有兩種途徑：

第一：如果你是直接用 java 命令在控制臺執行程序，可以用 java -version 查看當前的 JVM 版本，然后確定能接受的 class 文件版本

第二：如果是在容器中執行，而不能明確知道會使用哪個 JVM，那么可以在容器中執行的程序中加入代碼　System.getProperty("java.runtime.version"); 或 System.getProperty("java.class.version")，獲得 JVM 版本和能接受的 class 的版本號。

最后一絕招，如果你不想針對低版本的 JVM 用 target 參數重新編譯所有代碼；如果你仍然想繼續在代碼中用新的 API 的話；更有甚者，你還用了 JDK 1.5 的新特性，譬如泛型、自動拆裝箱、枚舉等的話，那你用 -target 1.4 -source 1.4 就沒法編譯通過，不得不重新整理代碼。那么告訴你最后一招，不需要再從源代碼著手，直接轉換你所正常編譯出的字節碼，繼續享用那些新的特性，新的 API，那就是：請參考之前的一篇日志：Retrotranslator讓你用JDK1.5的特性寫出的代碼能在JVM1.4中運行，我就是這么用的，做好測試就不會有問題的。

七：再議一個實際發生的相關問題

這是一個因為拷貝 Tomcat 而產生的 Unsupported major.minor version 49.0 錯誤。情景是：我本地安裝的是 JDK 1.5，然后在網上找了一個 EXE 的 Tomcat 安裝文件安裝了并且可用。后來同事要一個 Tomcat，不想下載或安裝，于是根據我以往的經驗是把我的 Tomcat 整個目錄拷給他應該就行了，結果是拿到他那里瀏覽 jsp 文件都出現 Unsupported major.minor version 49.0 錯誤，可以確定的是他安裝的是 1.4 的 JDK，但我還是有些納悶，先前對這個問題還頗有信心的我傻眼了。慣性思維是編譯好的 class 文件拿到低版本的 JVM 會出現如是異常，可現并沒有用已 JDK 1.5 編譯好的類要執行啊。

后來仔細看異常信息，終于發現了 %TOMCAT_HOME%\common\lib\tools.jar 這一眉目，因為 jsp 文件需要依賴它來編譯，打來這個 tools.jar 中的一個 class 文件來看看，49.0，很快我就明白原來這個文件是在我的機器上安裝 Tomcat 時由 Tomcat 安裝程序從 %JDK1.5%\lib 目錄拷到 Tomcat 的 lib 目錄去的，造成在同事機器上編譯 JSP 時是 1.4 的 JVM 配搭著 49.0 的 tools.jar，那能不出錯，于是找來 1.4  JDK 的 tools.jar 替換了 Tomcat 的就 OK 啦。

八：小結

其實理解 major.minor 就像是我們可以這么想像，同樣是微軟件的程序，32 位的應用程序不能拿到 16 位系統中執行那樣。

如果我們發布前了解到目標 JVM 版本，知道怎么從 java class 文件中看出 major.minor 版本來，就不用等到服務器報出異常才著手去解決，也就能預知到可能發生的問題。

其他時候遇到這個問題應具體解決，總之問題的根由是低版本的  JVM 無法加載高版本的 class 文件造成的，找到高版本的 class 文件處理一下就行了。

     摘要: VO(value object) 值對象     通常用于業務層之間的數據傳遞，和PO一樣也是僅僅包含數據而已。但應是抽象出的業務對象,可以和表對應,也可以不,這根據業務的需要.個人覺得同DTO(數據傳輸對象),在web上傳遞。     對于數據庫而言，每一個VO對象可以表示出一張表中的一行記錄，此類的名稱要與表的名稱一致。 B...  閱讀全文

       有許多標準和實踐準則可適用于Java開發者，但此處要說的，是每個Java開發者需堅守的基本原則。

　　一、為代碼加注釋。雖然每個人都知道這點，但有時卻不自覺忘了履行，今天你“忘了”加注釋了嗎？雖然注釋對程序的功能沒什么“貢獻”，但過一段時間，比如說兩星期之后或者更長，回過頭來看看自己的代碼，說不定已經記不住它是干什么的了。如果這些代碼是你個人的，那還算是走運了，不幸的是，當然了，大多數時候都是別人的不幸，很多時候大家都是在為公司寫代碼，寫代碼的人也許早已經離開了公司，但別忘了一句古話，有來有往嘛，為他人，也為我們自己，請為你的代碼加上注釋。

　　二、不要讓事情復雜化。程序員有時候總是對簡單問題想出復雜的解決方案，比如說，在只有五個用戶的程序中引入EJB、對程序實現了并不需要的框架（framework），之類的還有屬性文件、面向對象解決方案、多線程等等。為什么要這樣做呢？也許我們并不知道是否這樣會更好，但這樣做也許可以學到一些新東西，或者讓自己更感興趣一些。如果是不知道為什么這樣做，建議多請教經驗豐富的程序員，如果是為了個人的目的，麻煩讓自己更專業一點。

　　三、始終牢記——“少即是好（Less is more）并不總是對的”。代碼效率雖然很重要，但在許多解決方案中，編寫更少的代碼并不能改善這些代碼的效率，請看下面這個簡單的例子：

if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)＜0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)＞0)) ||
(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)＜0))){
newStatusCode = "NYP"; 
}

　　能看明白if條件語句是干什么的嗎？能想出來是誰寫的這段代碼嗎？如果把它分成兩段獨立的if語句，是不是更容易理解呢，下面是修改后的代碼：

if(newStatusCode.equals("SD") && (sellOffDate == null ||
todayDate.compareTo(sellOffDate)＜0 || (lastUsedDate != null &&
todayDate.compareTo(lastUsedDate)＞0))){
newStatusCode = "NYP"; 
}else
if(newStatusCode.equals("OBS") && (OBSDate == null ||
todayDate.compareTo(OBSDate)<0))
{
newStatusCode = "NYP"; 
}

　　是不是讀起來容易多了呢，在此只是多加了一個if和兩個花括號，但代碼的可讀性與可理解性就一下子提高了一大截。

　　四、請不要硬編碼。開發者經常有意“忘記”或忽略掉這點，因為有些時候開發日程逼得實在太緊。其實，多寫一行定義靜態變量的代碼能花多少時間呢？

public class A {
public static final String S_CONSTANT_ABC = "ABC"; 
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true; 
}
return false; 
}
}

 

　　現在，每次需要將“ABC”與其他變量進行比較時，不必記住實際代碼，直接引用A.S_CONSTANT_ABC就行了，而且在今后需要進行修改時，也可在一處修改，不會翻遍整個源代碼逐個修改了。

　　五、不要“創造”自己的框架（framework）。確切來說，有數以千計的各種框架存在，而且大多數是開源的，這些框架都是優秀的解決方案，可用于日常程序開發中，我們只需使用這些框架的最新版本就行了，至少表面上要跟上形勢吧。被大家廣為接受的最為明顯的一個例子就是Struts了，這個開源web框架非常適合用在基于web的應用程序中。是不是想開發出自己的Struts呢，還是省點力氣吧，回頭看看第二條——不要讓事情復雜化。另外，如果正在開發的程序只有3個窗口，就不要使用Struts了，對這種程序來說，不需要那么多的“控制”。

　　六、不要使用println及字符串連接。通常為了調試方便，開發者喜歡在可能的所有地方都加上System.out.println，也許還會提醒自己回過頭來再來刪除，但有些時候，經常會忘了刪除或者不愿意刪除它們。既然使用System.out.println是為了測試，那么測試完之后，為什么還要留著它們呢，因為在刪除時，很可能會刪除掉真正有用的代碼，所以不能低估System.out.println危害啊，請看下面的代碼：

public class BadCode {
public static void calculationWithPrint(){
double someValue = 0D; 
for (int i = 0; i ＜10000; i++) {
System.out.println(someValue = someValue + i); 
}
}
public static void calculationWithOutPrint(){
double someValue = 0D; 
for (int i = 0; i ＜ 10000; i++) {
someValue = someValue + i; 
}
}
public static void main(String [] n) {
BadCode.calculationWithPrint(); 
BadCode.calculationWithOutPrint(); 
}
}

　　從測試中可以發現，方法calculationWithOutPrint()執行用了0.001204秒，作為對比，方法calculationWithPrint()執行可是用了10.52秒。

　　要避免浪費CPU時間，最好的方法是引入像如下的包裝方法：

public class BadCode {
public static final int DEBUG_MODE = 1; 
public static final int PRODUCTION_MODE = 2; 
public static void calculationWithPrint(int logMode){
double someValue = 0D; 
for (int i = 0; i ＜ 10000; i++) {
someValue = someValue + i; 
myPrintMethod(logMode, someValue); 
}
}
public static void myPrintMethod(int logMode, double value) {
if (logMode ＞ BadCode.DEBUG_MODE) { return; }
System.out.println(value); 
}
public static void main(String [] n) {
BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE); 
}
}

 

　　另外，字符串連接也是浪費CPU時間的一個大頭，請看下面的示例代碼：

public static void concatenateStrings(String startingString) {
for (int i = 0; i ＜ 20; i++) {
startingString = startingString + startingString; 
}
}
public static void concatenateStringsUsingStringBuffer(String startingString) {
StringBuffer sb = new StringBuffer(); 
sb.append(startingString); 
for (int i = 0; i ＜ 20; i++) {
sb.append(sb.toString()); 
}
}

　　在測試中可發現，使用StringBuffer的方法只用了0.01秒執行完畢，而使用連接的方法則用了0.08秒，選擇顯而易見了。

　　七、多關注GUI（用戶界面）。再三強調，GUI對商業客戶來說，與程序的功能及效率同等重要，GUI是一個成功程序的最基本部分，而很多IT經理往往都沒注意到GUI的重要性。在現實生活中，許多公司可能為了節省開支，沒有雇用那些有著設計“用戶友好”界面豐富經驗的網頁設計者，此時Java開發者只能依賴他們自身的HTML基本功及在此領域有限的知識，結果，很多開發出來的程序都是“計算機友好”甚于“用戶友好”。很少有開發者同時精通軟件開發及GUI設計，如果你在公司“不幸”被分配負責程序界面，就應該遵守下面三條原則：

　　1、 不要再發明一次輪子，即不做無用功。現有的程序可能會有類似的界面需求。
　　2、 先創建一個原型。這是非常重要一步，用戶一般想看到他們將使用的東西，而且可以先利用這個原型征求用戶的意見，再慢慢修改成用戶想要的樣子。
　　3、 學會換位思考。換句話來說，就是從用戶的角度來審查程序的需求。舉例來講，一個匯總的窗口可以跨頁或者不跨頁，作為一個軟件開發者，可能會傾向于不跨頁，因為這樣簡單一些。但是，從用戶的角度來看，可能不希望看到上百行數據都擠在同一頁上。

　　八、文檔需求不放松。每個商業需求都必須記錄在案，這可能聽上去像童話，似乎在現實生活中很難實現。而我們要做的是，不管開發時間多緊迫，不管最終期限多臨近，對每個商業需求都必須記錄在案。

　　 九、單元測試、單元測試、單元測試。關于什么是單元測試的最好方法，在此不便細說，只是強調，單元測試一定要完成，這也是編程中最基本的原則。當然了，如果有人幫你做單元測試自然是最好，如果沒有，就自己來做吧，當創建一個單元測試計劃時，請遵守以下三條最基本的原則：

　　1、 先于編寫類代碼之前編寫單元測試。
　　2、 記錄單元測試中的代碼注釋。
　　3、 測試所有執行關鍵功能的公有方法，這里不是指set和get方法，除非它們是以自己獨特方式執行set和get方法。

　　十、質量，而不是數量。有些時候因為產品問題、期限緊迫、或一些預料之外的事情，導致常常不能按時下班，但一般而言，公司不會因為雇員經常加班而對之表揚和獎勵，公司只看重高質量的工作。如果遵守了前九條原則，你會發現自己寫出的代碼bug少且可維護性高，無形中質量提高了一大步。

    Tomcat5 及 Tomcat6 下CP配置。
    主要是根據MLDN的一個實例進行配置的。實例中用的是Tomcat5.5，所以他的CP配置如下：
    第一：將jdbc驅動的jar包，如：MySQL、Oracle的jdbc驅動，拷貝到tomcat中lib下。
    注意：必須是tomcat中lib下，如：D:\Tomcat 6.0\lib，但不能是項目中的WEB-INF/lib下，因為這時tomcat解析不到此類目錄。
    第二：在Tomcat的安裝目錄下conf下找到server.xml，在<host></host>之間加上如下代碼：
    第一部分為項目的發布路徑。其他的就是數據庫的配置了。
    第三：在Spring的配置文件applicationContext.xml中加上如下代碼：

    而我用的Tomcat是6.0.18，在根據這個配置后就會出現javax.naming.NameNotFoundException: Name jdbc is not bound in this Context的錯誤。原因是，Tomcat5和Tomcat6的配置有所區別：
    第一：將jdbc驅動的jar包，拷貝到Tomcat的lib下
    第二：在tomcat中conf下的context.xml文件中<context>與</context>之間加入以下部分：
    同時在項目的web.xml中加入如下代碼（網上說可以加也可以不加）

    第三：在Spring的配置文件applicationContext.xml中加上如下代碼：

    這樣，Tomcat6下的CP才能正常的運行起來。