摘自:http://www.javaeye.com/topic/28653
开发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好了。
但对于面向全球市场的产品来说,在开发之初不考虑多语言支持(不是没有啊),等有一天,公司老板决定要向全球推出该产品的时候,嗯,才发现,要对系统进行伤筋动骨的大手术,就等着哭吧。
其他观点,如下:
观点1:
1.跨应用服务器。这个痛苦我比较有体会。(注意:但tomcat5到4之间的的跨越可能意义不大,因为支持的servlet ,jsp spec版本不同;倒过来是应该完全兼容的。)
1.1 EJB跨应用服务器。虽然有spec,但每家都有自己的扩展,有些特别要命特性比如,EJB spec2.0里居然对like 只支持常数,就是不能传入?。
然后EJB的配置文件都有各自的扩展,真是痛苦。好在Jbuilder可以自动转换Weblogic到Jboss,但也不是那么好,总有魔鬼的细节要你反复调试。
1.2无EJB的跨应用服务器。这个容易多了,但居然也不是很顺利的。我的war曾经在tomcat上调试好了,发布到websphere5上就失败。最后用二分法逐次删除app里的文件,发现引起问题的居然是...eclipse产生的.classpath文件!websphere对eclipse支持得太好了吧?删掉即可。
这就算好的了。我后来把在tomcat5上调试好的war发布到resion3上,更郁闷。我在网上查了resion内置了自己的xml parser,导致我的castor xml无法正确执行,要更换parser,需要N步...遂放弃...
2.跨浏览器。这个绝不是很容易的事情。Javascript就够你喝一壶的,各种细微差别,各种特殊的扩展...,这个到罢了,到CSS,更有玩意,特别是主要用CSS布局的,有得玩,这一点上如果采取老式的Table布局,兼容性倒是很不错。还来新玩意要慎用。
3.跨数据库。
这个有hibernate之类的封装,就好多了。不用它,问题也不会很大,可参考我以前的帖子。(当然如果你用了stored procedure或trigger之类,只能手动挨个重写了)
4.跨操作系统。
这个听上去是最容易的。但我还是碰到了几个问题。
4.1文件路径的分隔符。windows下似乎能兼容Unix的分隔符,但反之不可。不能随意的用/或\,最好是用Java里提供的File.seperator。
4.2字符编码问题。一般我们会是用中文版的windows,默认编码是GBK;Unix可能会有差别,所以在使用new String(byte[]),String.toBytes()等与编码相关的操作时,要注意,可以指定编码。最好还是全部使用UTF-8。
5.国际化问题
这里暂只说文字的国际化。
需要将文字资源外部化,并且全部用UTF-8编码,根据Local选择文字资源等等。不难也不简单。
观点2:
我现在开发的时候,会同时用tomcat/resin/jetty/weblogic来测试。在linux当然非常简单了,做个符号连接就OK了。想用哪个就启动哪个好了。数据库会使用mysql/oracle/sqlserver,浏览器就用firefox。给我的感觉,只要firefox上跑起来没问题,在ie上基本都正常。可能有些css需要再细调一下,来保证效果的完全一致。比如event的触发、xy定位、script控制table等。
观点3:
我以前也以为‘只要firefox上跑起来没问题,在ie上基本都正常。’。
自从我使用CSS作布局就改变看法了。
IE有很多智能的判断,好还是坏难说,Firefox就没有。
比如一个DIV框,指定了高度,里面嵌入一个DIV,如果里面的高度比前者大,
IE里会自动扩展外部的DIV;
Firefox就不会,结果两个DIV的边框交错了...
补充几个我在实际开发中碰到数据库兼容性问题:
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