JSF 2.0
尽管 Java 在展示层框架上竞争的非常激烈,但 JSF 仍然固守着自己的领地。虽然有很多关于 JSF 的易用性和健壮性的质疑声,但 JSF2.0 就是为正面解决这些问题而提出来的,它的易用,创新以及可扩展的特性包括:
JSF 正式将 Facelets 作为视图技术。也许你不熟悉 Facelets ,它也是一个与 JSF 结合默契的开源视图技术。因此,与 JSP 不同的是 Facelets 更适合 JSF 的组件模型以及生命周期的概念。当然,也许 Facelets 最强大的特性就是在用 mark-up 来代替 java 代码创建自定义的组件。创建自定义组件的复杂度也许是开发者对 JSF 抱怨最多的地方了。
JSF2.0 通过使用标签为 Java EE 5 提供了基于 annotation 驱动的配置特性(比如说可以使用 @ManagedBean 和 @ManagedProperty )。这也意味着可以一定程度上的减少 faces-config.xml 文件的大小,不过像在 navigation 这些结点的配置在 XML 文件还是不能少。
JSF2.0 为适应 AJAX 而改变了自身的生命周期,只需要局部页面的交由 AJAX 事件处理。这个特性使得 JSF+AJAX 的组合更加自然。
JSF2.0 现在内置了优秀的资源处理器。对 images , JavaScript 文件以及 CSS 样式等都表现出众。它可以对通过逻辑名称,资源分组以及版本等方式来更好的引用资源。
除上述特性外, JSF2.0 还包括许多其它方便的改变。比如说支持事件,支持 RAILS_ENV 的开发风格 ( 就是 ROR) ,支持对标准组件集进行扩展。你可以通过下面的链接来看看 JSF2.0 的公开草案:http://jcp.org/en/jsr/detail?id=314
EJB 3.1
EJB 在 Java EE 5 就已经经历过了非常大的改动。也许看似不可能,但实际上 EJB3.0 还是在社区中广泛得到认可,并且采纳它的人也在不断增长。而这一切也许是因为我们过度的认为需要怎么怎么简化 Java EE 5 才取得这样的成绩。比如说,对 JBoss Seam 的兴趣和 GlassFish 的热情都是重要的关键因素。 EJB3.1 的目标就是在增加业务组件时,继续让 EJB 变得尽可能简单。下面是对 EJB3.1 特性的高度概括:
原本需要甚至实现 Session Beans 的业务接口变得可选了,不再强迫要求实现。在使用 Session Beans+JSF+WebBeans 的场景下尤其有用。
EJB3.1 增加了 Singleton Beans 的概念。因为人们更倾向于管理共享的应用程序状态,需要保证是完全线程安全的模型。此外, EJB3.1 新增的声明式的并发控制也更加灵活。
EJB3.1 一个可圈可点的的强大特性就是支持 cron 风格的 scheduling .除目前基于 timer API 的调度计时器外,声明式和编程式的 cron 风格的 scheduling API 也加入了进来。
另一个强大的特性就是可以通过使用 @Asynchronous 标注来对 Session Bean 的方法进行异步调用。你甚至还通过它来控制异步 EJB 方法从而返回一个 java.util.concurrent.Future 对象。
EJB3.1 Lite 概念的逐渐引入形成了一个 EJB API 的子集,并在 Web Profile 中得到应用。只不过 EJB Lite 包含了像事务处理和安全这样的特性,而那些消息机制,远程调用以及 scheduling 等非必须的自然没有必要加入其中。除上述列表所述特性外,
EJB3.1 的特性还包括:括直接将 EJB 打包成 war 文件,可运行在 embedded 的容器中便于 Java SE 环境进行 JUnit 测试,使用统一的标准化全局 JNDI 命名方式。 EJB3.1 的公开草案可从以下链接获得: http://jcp.org/en/jsr/detail?id=318
JPA 2.0
到 Java EE 6 的时候, JPA 已经彻底从 EJB 中分离,形成自己的体系 (EJB3.0 已经将 JPA 分离出去了 ) . JPA 的成功是毫无疑问的。它广泛得到社区的采纳和一流供应商的支持。本来我们担心 EJB2.* 的 Enity Beans 垮台可能无法让 Java EE 再次引领持久层的标准,一个重要成功的因素就是 Gaving King 和 JBoss 社区毫不含糊的支持。 JPA2.0 的目标就是要在这次成功的基础上再接再厉,填补更多的空白,再创多的创新:
JPA2.0 加入了大量必须的 ORM 映射增强特性,包括:支持通过使用 @ElementCollection 标注来增强 collections, maps 和 lists( 这里不是指实体之间的关联关系 ) 集合,支持 map 的单向 one-to-many 关联 (JPA1.0 只允许双向 one-to-many 关联 ) .
EntityManager 和 Query API 都得到改进。比如说,现在可以从结果集中直接取得第一条记录 (JPA1.0 只允许从一个 unique 结果集中反回单个记录 ) ,指定 query 结果集的最大值,访问各个供应商的底层实体对象 manager 或 query ,最后就是加入悲观锁 (JPA1.0 只支持乐观锁 ) .
JPQL 也提供类似于 SQL 的 CASE , NULLIF , COALESCE 等函数 .
JPA2.0 应广大开发者要求增加了 Criteria API .要是你对 Hibernate 或 TopLink 的 Criteria API 不熟悉的话,可以将它想像成一个以 Java 为中心的面向对象,线程安全并可以与 JPQL 划上等号的一组 API .这组 API 适合于编写复杂的动态查询语句,还可避免解析 JPQL 语句时,所抛出的运行期异常。
更完整的 JAP2.0 特性还包括:标准的二级缓存,标准的 JDBC properties ,指定超时时间等等。你可以随时通过下面的 JSR 站点看看关于 JPA2.0 公开草案的更多细节: http://jcp.org/en/jsr/detail?id=317