开发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好了。
但对于面向全球市场的产品来说，在开发之初不考虑多语言支持（不是没有啊），等有一天，公司老板决定要向全球推出该产品的时候，嗯，才发现，要对系统进行伤筋动骨的大手术，就等着哭吧。