跨平台技術

一般的計算語言都可做到跨平台，開發商只需要提供各種平台下的Runtime/中間件環境即可。嚴格而言是指用某種計算機語言編制的程序只需要做小量的修改，編譯之後即可在另外一種平台下運行，此時並不提供Runtime/中間件環境。例如Java是一種提供Runtime環境的跨平台解決方案，而C只是一種標準且嚴格的跨平台語言。

是軟件開發中一個重要的概念，即不依賴於操作系統，也不信賴硬件環境。一個操作系統下開發的應用，放到另一個操作系統下依然可以運行。相對而言如果某種計算機語言不用修改代碼即可做到高度跨平台，那麼此語言就越抽象，硬件控制力就越低，只適合開發高度抽象的模型系統。諸如java,delphi和易語言，都已做到了跨平台。它們將可以在多種系統下開發，運行和維護。

大部分電腦語言從絕對意義而言

都是跨平台的：因為都是以高級的、人類可讀的方式來對CPU發號指令，這樣也就沒必要依賴於任何作業系統。但如果要用系統的部件工具箱，來新建用户圖形界面（GUI），就可能會用到開發員特定系統中的API函數或庫類。雖然C++是跨平台的，但Windows下用到Win32 API的C++程序，一般就不能在Unix機器上編譯。不同編譯器對語言規範的解釋也有所差異。這樣的話，在針對不同系統進行構建之前，程序就得加以考慮。

一些如Java這樣的語言，從一開始就意識到要在各個平台下運行，所以跨平台在其平台的本地語言環境中已經實現。例如，Java可以跨平台使用，正是由於Swing庫在許多平台下的實現。類似的，能進行跨平台的文件存取，是因為有各自平台下文件存取的庫（實際上java裏面的部分東西在windows平台下編寫好後，移植到Linux平台下是會出現少許問題的，問題比較小並且不多，我們還是可以理解為sun公司所説的跨平台的）。以此類推，各種跨平台問題，都需要各自的本地庫來解決。wxWidgets框架就是這樣的一個跨平台庫，根據不同的跨平台問題，提供了許多不同的解決方案；類似的庫有許多，可以根據不同語言的跨平台開發，而採用相應的庫。

針對每種作業系統、CPU，而提供並測試各自的編譯版本，這種做法的可行性很小；開源軟件則允許用户自己來編譯目的碼（object code），這樣在跨平台方面更好一些。類似的，那些解釋型語言，或者需要虛擬機的語言，也更加符合跨平台的要求，因為用户也要自己進行編譯。Sun公司的Java虛擬機Hotspot，只針對幾種而不是全部平台，提供編譯好的二進位文件。例如，Sun對於GNU/Linux，只支持i386平台，但如果誰在PowerPC或者SPARC電腦上運行Linux，就只好自己編譯本地的機器碼（machinecode），或者使用第三方軟件，才能運行Java程序。

許多API（應用程序介面）依賴於平台。OpenGL可以看作是跨平台的，因為其不依賴於任何特定的作業系統、CPU構架或者某個牌子的圖形設備。特定平台的API可以在其他系統上作為兼容層而新建，例如WINE的庫，Windows程序就可以在UNIX系統上運行。

另外許多程序語言還有跨平台的擴展以及中間件，這樣程序設計師對於同樣的原始碼，只要進行一點小修改，就可以在不同平台下編譯/運行，例如Qt和wxWidgets。

這一點，看起來好像有些多餘，java的口號之一不就是“一次編譯，到處運行”嘛，可實際經驗告訴我們，這僅僅是一個口號而已。實際中是“一次編譯，到處調試”。為什麼會這樣？從應用服務器來説，各個產品或多或少都在標準的java規範之上進行了一些拓展，小規模的應用開發，多以tomcat為基準；大規模的應用，多以weblogic/websphere為基準。

那麼開發完成的應用，可否在所有的應用服務器上正常部署呢？答案是否定的。在tomcat5上部署沒問題，在tomcat4上卻可能有問題；在tomcat5/4上沒問題，卻可能在resin/jetty/weblogic/websphere上有問題。在我的經歷中，在resin/jetty/weblogic為基準進行開發的應用，部署到tomcat上基本上沒什麼問題。但是以tomcat為基準的應用，部署到其他應用服務器中，卻可能出現各種各樣的問題。這與tomcat本身的定位和開發方式有關，它更像是一個學術產品，而不是一個商業產品。

小型的應用，我偏好resin，它的速度、穩定性、兼容性、中文處理，都是非常不錯的。相比而言，以“純java、快速”著稱的jetty，就不太令人滿意。jetty的4/5/6各個版本中，對session的存放位置、web.xml的標準、struts的plugin的支持、log4j的處理，都各不相同。在最新的jetty6中，竟然會要命地“不能使用session.validate()”方法，一使用此方法之後，就無法再使用set/getAttribute了。

也曾經在將一個應用轉移到websphere5上時，費勁周折。這個應用跑在其他應用服務器上都沒問題，但是一部署到ws5上，就無法正常加載struts的配置文件。本以為是struts配置文件寫得有問題，但即便把所有的action/form配置均去掉，只保留一個空的配置文件，也無法正常啓動。最後實在無法，只能亂碰運氣，考慮是否是struts的幾個jar包版本有問題，經檢查，發現應用中使用的是struts1.2的jar包，換成struts1.1的jar包，再啓動後就一切正常。這樣的問題，可真的是折磨人呢。

所以，我認為跨應用服務器是很重要的。你不能告訴客户，俺們的系統只能跑在tomcat下面，至於您花重金購買的weblogic/websphere，對不起，我們暫時還不支持。客户會吐血的。

經常看到某大公司產品，要求必須使用oracle或者sqlserver數據庫，你想換個數據庫來部署？沒門，人家説了，我們的產品只支持這一種數據庫，你就老實的用吧。但對於客户方來説，為了減少投資，並且保證內部系統儘可能使用同一種數據庫以減少維護成本（總不能請一個oracle DBA，再請一個sqlserver DBA吧？），總會希望新系統使用的數據庫是以前用過的吧。

有了hibernate，在此基礎上開發的應用，基本上是能滿足跨數據庫要求的，個人認為這是hibernate最大的亮點。但也要注意，在開發中儘可能考慮到不同數據庫的特性。諸如sqlserver的text/image字段上不能查distinct，oracle內的各種對象名稱長度不得超過30等，儘量不要調用數據庫的內部特性（如存儲過程、視圖等）

這一點，貌似沒有什麼可説的，很少有開發出的系統只能部署在一種操作系統上的。不過有一點也要注意，如果系統中某些功能依賴於通過JNI來調用windows本地組件的話，比如打印、word/excel操作，或與只能運行在windows下的報表組件(如國內的數巨報表、如意報表)集成的話。

竊以為，如果只是做國內的應用，這一點倒不重要，就以IE為標準來開發也未嘗不可。

PS：完全支持IE也不是一件容易的事情，IE5/6本身就有不少的差異。

但如果產品本身想立足於世界，想與國外產品競爭，對瀏覽器的全面支持也必不可少。至少應該同時支持ie和firefox吧，如果對自身嚴格要求的話，我認為應以opera為標準，opera對html/css/javascript的標準是實現和支持得最好的瀏覽器。