你的系统是跨平台的吗？

开发java应用，听到的最多的一句话就是“跨平台”，那么现在小声的问一句，你开发的系统真的能跨平台吗？
以我的拙见，所谓的跨平台，包含五方面的内容：
一、跨应用服务器
二、跨数据库
三、跨操作系统
四、跨浏览器
五、多语言支持

下面分别来说一下。
■跨应用服务器
　　这一点，看起来好像有些多余，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的标准是实现和支持得最好的浏览器。
■多语言支持
　　如果您的产品只想在中国卖，根本就不考虑世界市场，那这一条就pass好了。
　　但对于面向全球市场的产品来说，在开发之初不考虑多语言支持（不是没有啊），等有一天，公司老板决定要向全球推出该产品的时候，嗯，才发现，要对系统进行伤筋动骨的大手术，就等着哭吧。

评论

25 楼 gigix 2007-06-02  

一次惨痛经验以后的教训：一定要尽早部署、频繁部署。部署时候会出现的问题几乎总是最难对付并且致命的。

24 楼 tmp 2007-06-02  

跨平台？
就是桌面应用也不一定可以保证，更不用说企业级了。
口号而已!

23 楼 qq17906 2007-05-15  

不错得文章。受教了！

22 楼 amozon 2007-01-29  

没必要因为三个非洲人浏览过你的网站，就弄个非洲语言兼容他。。。

21 楼 wzgme 2007-01-29  

hurricane1026 写道

弱弱的问一下，QT可以用来C++跨平台么？我光在广告上看到了。

我的一个小小的体会，Win下的Qt支持还是比较弱，除非购买Qt商业版进行编译。

目前不少开源的基于Qt的C++项目，自己想在Win下编译成功，还是比较费劲。

Qt Designer还比较好用，无论Win，还是Linux。

20 楼 whisper 2007-01-28  

java is not platform independent, it is the platform
从来都看不上这东西
没有新意，又不曾真心解决问题

19 楼 china2wto 2007-01-28  

国际化其实是最最烦的，大家都考虑的太太少了！操作系统有几种？tomcat,weblogic等应用服务器你能遇到几种？数据库你能说出几个？我想都不会超过10个吧？但全世界有几百种语言！每种语言文字语法都不同，这个也许你会认为struts等MVC架构系统的能够解决，但是大家是否考虑到文字的方向性呢？


如果使用了阿拉伯语、波斯语、希伯来语、印地语、泰语、越南语或乌尔都语等语言则文字读写方向是从右向左的。在排版的时候怎么排版就是一个巨大的头痛的问题。如果在这些语言中再夹杂英语单词的话（例如我这篇文章就在中文中夹杂了英语单词），英语是从左往右写的，这时候整篇文章就是双向文字排版（你不可能在阿拉伯语排版中将weblogic写成cigolbew吧？）。
还有树状菜单靠右放置的问题，搜索按钮放在文本框左侧的问题，翻页按钮 “下一页”放在左侧，“上一页”放在右侧的问题，这些左右方向问题，在现在的国际化模块中都无法实现。
不过还好，中国外包项目国际化大多数都只涉及到英语、法语、西班牙语等拉丁语系以及中文、日文、韩文，这些语言都是从左向右的。

（另外：我还听说古代印度河流域以及古希腊文好象是第一行从左向右书写，第二行再从右向左写，我要是遇到这个项目，我要吐血了。）

18 楼 叶子 2006-10-23  

js还好

css的话,就算是yahoo等的首页,在ff下也报很多错误..

17 楼 eason007 2006-10-23  

一直没有觉得js和css在跨浏览器上同时应用有多困难。不知是否我做的应用比较浅薄。

基本上这两样只有遵照w3c的指示做是没什么问题的。

16 楼 Tin 2006-10-23  

服务器端如果没有用到厂商私有API，那么通过服务容器的向下兼容特性，我们的应用都应该是可以跑的。不用总假想让低版本的服务器跑得应用，开发部署应该是我们可以掌握的。
还有一点思路问题，选择高端的J2EE server很多时候是从性能可扩展、安全等很多角度考虑的，所以跨平台不是第一要务，此时反而会鼓励使用私有API，在此时应该解放思想。

而客户端，一般就是定好最低版本，考虑一下可访问性的底线是哪里，然后多测试。css布局麻烦在自动适应分辨率的相对布局上面，这个多遵循经典的惯例，适当的使用浏览器欺骗hack，应该能够达到不错的效果。客户端的界面是不完美的艺术，我们的目的是“可访问”，而不是看起来一样。这里不用犯完美主义的毛病:D

15 楼 hiwzg 2006-10-22  

各位总结得是，请继续补充:)
这个帖子值得收藏，呵呵。

14 楼 liuwangxia 2006-10-21  

together 写道

■跨数据库
经常看到某大公司产品，要求必须使用oracle或者sqlserver数据库，你想换个数据库来部署？没门，人家说了，我们的产品只支持这一种数据库，你就老实的用吧。但对于客户方来说，为了减少投资，并且保证内部系统尽可能使用同一种数据库以减少维护成本（总不能请一个oracle DBA，再请一个sqlserver DBA吧？），总会希望新系统使用的数据库是以前用过的吧。
现在有了hibernate，在此基础上开发的应用，基本上是能满足跨数据库要求的，个人认为这是hibernate最大的亮点。但也要注意，在开发中尽可能考虑到不同数据库的特性。诸如sqlserver的text/image字段上不能查distinct，oracle内的各种对象名称长度不得超过30等，尽量不要调用数据库的内部特性（如存储过程、视图等）

补充几个我在实际开发中碰到数据库兼容性问题：

1）唯一约束
SQL server 2000, HSQLDB 1.8, PostgreSQL 8 都允许唯一约束中存在可为空值的字段，而 Derby 10 则不行；

2）Hibernate 中的没有指明长度和精度的 decimal 映射到 Firebird 时会报错，提示长度超过；
Firebird 中 Decimal 总长度不能超过 18

引用

Decimal(P,S)      变数(16、32或64位）      精度p从1到18：指定数字的总长度；标度s从0到18：指定小数点后的位数。      定点小数。例如decimal(5,3)可以存储的数字形式为：pp.sss

3）中文表名、字段名
PostgreSQL 8, SQL Server 2000, Derby 10, HSQLDB 1.8 对中文表名、字段名支持很好；
MySQL 5 支持的不是很好，中文表名、字段名必须有偶数个汉字，否则有问题；
Firebird 2 还有些问题，SQL 语句中的中文表名、字段名必须放在单引号对里面。

4）varchar 的长度限制：
PostgreSQL 8        varchar(10485760)
SQL Server 2000        varchar(8000) nvarchar(4000)
Firebird 2         最大 32767 字节，字符数根据编码各不相同
Derby              最大 32672 个 unicode 字符

5）Firebird 的索引长度限制，不同版本不一样，Firebird 2.0 要好些。
Firebird 1.5 最大索引长度为 252

引用

Firebird 2.0 最大索引长度与设置PAGE的大小有关,即最大索引长度(字节)=PAGE/4-4,如下表:
　　PAGE 大小(字节) 最大索引长度(字节)
　　1024 252
　　2048 508
　　4096 1020
　　8192 2044
　　16384 4092

Firebird Index key size calculator

13 楼 YuLimin 2006-10-21  

Lucas Lee 写道

2.跨浏览器。这个绝不是很容易的事情。Javascript就够你喝一壶的，各种细微差别，各种特殊的扩展...，这个到罢了，到CSS，更有玩意，特别是主要用CSS布局的，有得玩，这一点上如果采取老式的Table布局，兼容性倒是很不错。还来新玩意要慎用。

同感，用Table还是在不同的浏览器间支持还是可以的，虽然说。。。

Lucas Lee 写道

  4.1文件路径的分隔符。windows下似乎能兼容Unix的分隔符，但反之不可。不能随意的用/或\，最好是用Java里提供的File.seperator。

在Windows或非Windows的操作系统统一用/即可，大家都认：）

12 楼 robbin 2006-10-21  

叶子 写道

1.暂时都没拿tomcat调试,resin应该问题不大的吧.
2.跨数据库真的觉得蛮鸡肋的东西,开始就确定数据库就好.
3.没test,暂时还只是win
4.自己写了个小framework,跨浏览器上还好.不过css确实没办法,只能很多特性不用就是了...
5.没研究...

跨数据库我还是很看重的。

11 楼 叶子 2006-10-21  

1.暂时都没拿tomcat调试,resin应该问题不大的吧.
2.跨数据库真的觉得蛮鸡肋的东西,开始就确定数据库就好.
3.没test,暂时还只是win
4.自己写了个小framework,跨浏览器上还好.不过css确实没办法,只能很多特性不用就是了...
5.没研究...

10 楼 LucasLee 2006-10-20  

xiaoyu 写道

国际化问题补充一点. 大家只想到了文字, 其实应该还有图片,还有阅读习惯,还有因为语法问题, 导致传入的参数个数不一样(这样很麻烦). 所以国际化问题其实很复杂.

图片问题相对简单，就技术而言，图片不过是另一种资源而已，在系统中，特别是b/s系统中，就是一个URL路径，这一点上，跟普通的文字资源一样。

整个问题的确很复杂，更深入的暂不谈。

9 楼 xiaoyu 2006-10-20  

国际化问题补充一点. 大家只想到了文字, 其实应该还有图片,还有阅读习惯,还有因为语法问题, 导致传入的参数个数不一样(这样很麻烦). 所以国际化问题其实很复杂.

java的跨性, 我觉得还是非常不错.

至于应用服务器这个, 如果是完整按照规范的话, 兼容应该没有什么问题, 特别是那些经过sun验证过的.

数据库, SQL做得太好了.  短小, 精干.

觉得用AJAX后来会变成灾难.

8 楼 foxty 2006-10-19  

一、跨应用服务器
   平时用的最多就是tomcat，resin使用过，但是部署的时候没发现什么问题，没有太多经验，所以这个就不说了。

二、跨数据库
    这个我觉得不应该归属与java的问题，而是各个数据库厂商的原因，各个数据库都有自己的特性，这种东西是没办法统一标准的。

三、跨操作系统
    如果是pure java的程序，只要注意不使用和操作系统相关的调用就没问题，上面说的文件分隔符使用File.seprator就能很好的解决，记得我曾经碰到的一个问题就是在unix上要调用shell脚本，确实很麻烦，开发环境是windows，只能另外写一个测试类放到unix上去测试这个调用。如果不包含这些东西，夸操作系统是没有问题的。

四、跨浏览器
    最近做了很多关于javascript的程序，头疼的紧，而且我还是仅仅要求兼容ff和IE，不过不兼容的地方都是dom上的一些操作，反正只要是涉及到dom操作的，我都是两个浏览器一起开，测时一直是跟着编码后面，生怕哪一段出了问题，查起来N麻烦。 不过很多地方操作可以使用开源的js库，他们都能很好的避免这些问题，还是能节省不少力气的。


五、多语言支持
    这个我觉得是没有问题的，现在的framework哪一个没有i18n。

7 楼 Arath 2006-10-19  

对跨平台自己有些研究，不过我是用C/C++的，一次编译到处运行是不行，但至少可以使得跨平台来的容易.
从语言角度，C/C++语法早已是工业标准，当然有些细微的问题上会有不同，但这不影响，最大影响的是OS API和Data Type, 所以使用C/C++作跨平台开发首先要把Data Type和OS API自己重新定义和规范好，这样就可以起到隔离的作用，换了一个平台只需要重写这些基本封装就可以了，而上层的大量代码无需更改.
在语言中不要用很多偏门的或者说过于高阶的语法或功能，比如template, 这些在跨平台的时候带来的问题会比较多.
不要使用与OS紧密相连的封装机制，例如在Windows下的COM, 这样不会因为换了OS而作废的情况发生.
数据流，可能遇到采用的硬件的数据编码方式不同的情况，对这种情况一般可以强制定义自己的数据采用何种方式，大尾或小尾, TCP/IP就是强制的.或者加上一些数据位表示也是解决之道.
和OS或某些AP紧密相连的部分，例如WEB等直接封装，然后以统一接口导出功能，这样跨平台时只会影响这一部分而不会影响整个程序.
数据库，只能做到在接口层的隔离，所以可以选用ODBC，同样作为工业标准，基本上通用的数据库都支持，而且自己如果再作一下简单的封装会更好.

其实做到跨平台性真的很难，所做的很多努力实际上只是为了降低跨平台带来的成本而已.

6 楼 together 2006-10-19  

嗯，所以需要看效果来细调。总会能调到在几个浏览器里的效果一样的。