【IT168 分析评论】又看到 Reza 同学为 Java EE 6 奔走呼告了。如同在浩浩荡荡的就业大军中的一员， Reza 带着自己的最新“简历”—— Java EE 6 ，向咱们开发人员展示耳目一新的感觉。但从本文的字里行间中，隐隐约约还是能觉察到它的困惑和迷茫：“已经付出了这么多， Java EE 6 能再次成功吗?开发者会采纳它吗?如果不是，我们还应该做什么?......”。当年 EJB2.* 的垮台掀起了反对使用 EJB 的浪潮。实际上我接触 JavaEE 比较晚 ( 大概在 2007 年初 ) ，没有使用过 EJB2.* ，但也是不够客观的照着大家说的抨击 EJB ，天天嘴边挂着 Struts ， Spring ， Hibernate 。但随着对 JavaEE 的不断关注与了解，渐渐发现自己的盲从于无知。此次 Java EE 6 的特性预览更有让我渴望学习它的冲动。“技术选型的抉择政治因素往往大于技术本身 。” Java EE 6 的推广还应该要更多的成功实战项目来赢得“政治因素”。但如同刚毕业的应届生，没有经验也要面对就业，除实力本身外，靠的就是运气了......
简单回顾
Java EE 5 是一个相当成熟，布署广泛并且支持服务端友好开发的平台。 EJB 3.0 的引用已经颠覆了原有的业务组件开发模型，而原有 EJB2.x 的 Entiy Bean 模型由持久层的 JPA 来代替。 JSF 也被作为官方的标准展示层框架，当然还有咱们的 JAX-WS 2.0 代替了 JAX-RPC 作为新的 SOAP web services API 。 Java EE 5 的目标非常明确——通过引入 Annotation ， POJO 编程模型，零配置 (zero-configuration) 等一系列概念从而降低开发的复杂度，帮助开发人员从 XML 地狱中解脱出来。尽管对 Java EE 持观望态度的还是大有人在，但是也许要证明“实际上 Java EE 5 已经获得成功”的最有利的证据就是由于上述提到的种种改变，使得很多家伙第一次开口说他们已经考虑接受 Java EE 。还是这帮家伙，在体验 Java EE 编程模型后，不断的向我们反馈他们的震惊。
大局观
Java EE 6 又将是迈向理想中那简洁，高效以及整合完好平台之旅的一大步。 Java EE 6 又有了一系列技术上的革新：有全新的 WebBeans1.0 和 JAX-RS 1.1 API ，也有更加成熟的老牌 API Servlet3.0 。
除少数相对较小的改变外 ( 比如说标准的全局 JDNI 命名，本文将不会谈到 ) ，大多数 JSR 316 中的主题都是精挑细选出来的。现在咱们就一同来看看这些变化。想了解更多细节，我推荐你把公众审议草案下载下来看看。这是链接地址： http://jcp.org/en/jsr/detail?id=316 .
砍掉没用的 API
Java EE 的第一版发布于 1999 年。在竞争异常激烈的业界一直作为官方标准，那时间也不算很短了。但在这段时期里， Java EE 只是一味的在成长，结果导致到现在平台变得臃肿不堪，充斥着一堆毫无用处的过时 API ，用起来不爽，布署起来也不方便。 Java EE 6 开始正儿八经的处理这些 API ，确保平台更加轻量级，同时也是为了腾出更多的空间，更利于 Java EE 的健康成长。表 1 显示了那些被砍掉的 API ，当然原因我们也做出了说明：
被砍的 API | 被砍原因 |
JAX-RPC | JAX-RPC 是早期通过 RPC 调用和 SOAP web services 进行交互的编程模型。由于 Web services 成熟后从 RPC 模型中分离出来，更加健壮，更多特性和流行 JAX-WS API 实际上已经代替了 JAX-RPC 。 |
EJB 2.x Entity Beans CMP | 复杂，笨重，过度复杂的 EJB2.* 的 Entity Bean 模型已经被 Java EE 5 的基于 POJO 的流行轻量级 JPA 持久层模型所代替。 |
JAXR | JAXR 是 Java API 中少数几个用于 UDDI 注册服务的接口之一。遗憾的是，由于 UDDI 并没有广泛使用，现在 JAXR 已经几乎没有啥应用，而且供应商支持的也很少，难免遭到被砍命运。 |
Java EE Application Deployment (JSR-88) | JSR 88 是当初是用于 J2EE 应用程序在应用服务器上进行的配置和部署的标准 API 。可是该 API 始终没有得到众供应商的支持，不得不砍掉。 |
Java EE Management (JSR-77) | 和 JSR 88 有着相似的命运， JSR77 原本是用于为应用服务器创建监控管理的 API 。可是各大供应商热情仍然并不高涨，难逃被砍命运。 |
上述精简 API 的原则上是，应用服务器供应商不需要强制的去支持这些技术，但是不排除一些大型的供应商仍就会对这些被砍 API 继续维持一段时期。
对于此次调整你有什么看法?太过于激进了?还是仍然过于保守?你还用上述表格中看得到的 API 吗?还有其它你认为也应该被砍掉的 API 吗?
