java代碼不變引用的包改變引起編譯結果的改變
最近在升級招投標網站的struts2時發現了這樣的事情：java源代碼不變，引用的庫改變會使編譯的class文件改變。
最開始時在本機xp下調好升級struts2.0.14到2.3.4後，上傳至服務器，發現出現錯誤：NoSuchMethodError ...context.get(Object)在FileUpLoadIntercepter中。在本機虛擬安裝服務器操作系統windows server 2003 x64裝上卻無此錯誤。
在xp環境下恢復2.0.14後也出現此錯誤。仔細對照改變的東西，除了lib下一堆jar外就是web.xml不一樣。
抱着試一試的心態將2.0.14的class替換掉2.3.4的，居然不再報那個錯誤了。
仔細一想，原來源代碼裏有一個自己更改過的struts2源文件FileUpLoadIntercepter，將別的class復原，單替換這個class文件，果然是這個class文件變了。
源代碼一樣，反編譯查看結果也一樣，但是這兩個class就是不一樣，不一樣的原因是這個源文件所引用的包變了。由struts2.0.14的包變成了struts2.3.4的包。
過了兩天，同事身上又發生了類似的事情：只改變了bean下面的一個類，action卻拋出異常；又是抱着試一試的心態，將新編譯的同類action的class文件拷貝到服務器上，問題得以解決。
以同事的例子試做說明：同事的bean裏原來是int a;int getA();void setA(int a),action裏調用的是setA(...)。升級strtus2後bean改變成Integer a;Integer getA();void setA(Integer a)。只把改變後的bean放到服務器上，服務器報NoSuchMethodError setA(I)V，把編譯後的action也換掉後，不再報錯。推測原因是在eclipse環境下，bean更改後，eclipse自動把action重新編譯了，action中的調用有setA(int)改成了setA(Integer),這樣只換bean不換class就得到了上述的錯誤。