一如既往，本文不涉及过多的J2EE开发的技术细节，如果想关注这方面内容，请参阅其他书籍。本文也不适合J2EE开发的新手作为入门教材阅读，谢谢配合。本文的主要目的是整体的介绍一下J2EE开发在我眼中的现状，以及个人对未来趋势的一些看法。
首先，先谈谈EE这两个字母。所谓的EE，就是Enterprise Edition，企业版。顾名思义，这个东西是针对企业开发来制定的。那么讨论一下，企业开发需要什么东西？
第一，肯定是压倒一切的稳定。作为企业来说，商务才是第一位的东西。技术什么的，在商务面前都是要让步的。你技术再先进，良品率不高也不行。或者你技术独步宇内，但是只有你一个人能做，那也是不行的。而商务需要的东西，从技术层面来说，是稳定和高效。也就是说，你首先得稳定，最好是MTBF非常高。其次是高效，最好是几KB内存能搞起一个网站来。
第二，是易用。也就是说，最好你能自己猜测用户心意。用户咳嗽一下，你就知道用户要填啥；用户皱皱眉头，你就知道用户想点哪个按钮。
那么，在实际开发中，除了这两点以外，还有什么是企业级应用中比较关心的呢？就是两个字，支持。这里的支持除开对Bug的及时修复以外，还有就是对客户其他方面的一些支持。比如业务有改变了，你的修补速度等等。
现在来谈谈稳定。高效，易用，支持，这三个主题会分别在接下来的三篇里提及。为避免一篇内容过多，所以分成四篇来写。
谈稳定之前，先来看几个概念。
第一个是鲁棒性，英语原文的Robust。所谓鲁棒性就是系统的健壮性，它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器(以上内容来自百度百科)。
而稳定在J2EE系统来说，表现在一个一个的框架的堆叠，每个部件的稳定，造就一个系统的稳定。而一个一个的框架的稳定，来源于广大用户的测试。
J2EE世界很崇尚自由的风格，所以也造就了很多免费的框架，其中最典型的就是Rod Johnson开发的以一己之力挑战EJB的Spring。现在Spring的主版本号已经到3了。Spring 1我没用过，不置可否。2和2.5我用过，开始尚且可以习惯，所有的核心类都在一个jar文件内，配置框架的时候有MyEclipse的协助，还行，不算很难。只不过呢，有的时候用到一些比较少见的类的时候，就比较受罪了。因为分布于很多jar中，不知道到底是哪个jar，又不能一起甩进去，也不能一个一个试验，没时间，没精力。比如我写tag的时候，本来是继承TagSupport的，如果要从Spring Context中获取到request的话，要继承一个叫RequestContextAwareTag的类，来自于org.springframework.web.servlet.tags.RequestContextAwareTag。虽然这些都可以查到，但是说实话，以一己之力，想了解全貌，实在太难了。
更让我吃不消的，是Spring3的发布。Spring3将原先的几个主要的jar全部拆散，我第一次用到的时候，看到了满眼的文件夹以及满眼的jar文件，当时第一反应就是两眼发直，傻掉了。因为又缺少必要的本地化文档支持，又缺少时间来研究到底哪些jar是必须的，最后只好作罢，放弃使用这个框架。而如果回头使用2.5的话，又有些不甘心。因为玩的基本上比较熟了，想挑战一下自己。况且，能引起主版本号变化，肯定是有很多的改变的。最后在两难的抉择下，只好放弃了Spring。而一旦放弃Spring，基本上就意味着放弃了其他主要框架，比如Struts2。最后实在是没办法了，只有拿出原先搭配好是Spring2.5+Struts2的一套代码，完成了这个项目。
其他的框架就不再表过了，比如Struts1的为人诟病的难以解耦，Hibernate的性能问题，这些都是无法面对又不得不面对的问题。
不可否认，除开上面这些问题，SSH这三个框架是十分经典的。每个框架都很经典，对开发模式的理解和其他功底都很深刻，只是，我实在是有话要说。
优秀加上优秀并不等于另一个优秀，很有可能是无法接受的结果。
比如说，SSH框架，从入手到熟悉到能调试各种千奇百怪的Bug，至少需要一年时间，而且是外包的工作方式，也就是纯粹的码农，在无尽的实战中加深理解，遇见各种问题。而且，从另一个层面来讲，三个框架的风格并不一致。比如说，Spring因为自身功能复杂，导致了xml文件的编写方式非常复杂；Struts2因为来自WebWork和Struts1的关系，配置文件是一脉相承的。Hibernate的话，基本是个OOP性质的配置文件。三个风格各异的配置文件，凑在了一起，那么。。。反正我是没招架住，放弃了。所以我到现在还是不会用SSH，呵呵。好在我求职的话，已经不需要再拿SSH说事了，算是侥幸。
所以说，J2EE的稳定是有代价的，就是开发人员的操劳和不断的学习。而这种学习，又不是能轻易解决的，需要长时间的，坚持不懈的学习。最无奈的是，这种学习是一过性的，也就是说，你学习的知识一旦被主流开发抛弃，那您就只好从头再学一遍啦。
所以呢，我一直发现一个比较有意思的现象。在每期程序员的开头，都有一些文章是各种技术前沿的文章。所有的微软系的技术专家都是红光满面的，而Java系的技术专家都是很劳累的样子。学的太多了，能不累么。学完SSH了，如果公司要用什么新框架，还得学。再过一阵公司说要用EJB了，还得学。而且学过EJB2再学EJB3,基本等于重新开始。
发完牢骚，我最后想提出一个问题。J2EE的这些框架，真的稳定么？不尽然吧。都是社区的杰作，常规使用当然没问题，但是高密度的商业应用呢？比如我们一天24亿条数据，数据量达到每天80GB的应用，我还真不敢拍胸脯。
要下班了，晚上有人请客吃肯德基，呵呵。明天来谈J2EE的高效。