EE4J , JSF 规范 , MyFaces 和未来方向

EE4J , JSF spec , MyFaces and Future direction

在 JSF 2.3 之前,mojarra(参考实现)和 myfaces 都是基于 JSR 规范文档。

迁移到 EE4J:

  1. 是否有任何等效的规范文档?
  2. 它如何影响其他实现的未来(jsf 的 myfaces)?
  3. 未来的 mojarra 和 myfaces 是否仍然兼容,以便我们可以 运行 在其中任何一个上应用程序? (应用服务器提供的实现 - WAS = myfaces & glassfish = mojarra)
  4. 它对 Primefaces、Bootsfaces 等依赖于底层实现的组件框架有什么影响?

2018 年 8 月 19 日更新: Guillermo González de Agüero 最近 interview at Jaxenter.com 解决了您的一些问题。特别是,他有点担心 Oracle 不会开源规范文档。这将防止简单地将这些文档作为新规范文档的基础。

2018 年 8 月 17 日更新: 在写完我的初始答案后,我联系了一些领先的 ​​JSF 开发人员(参见 this discussion on Twitter)。有计划清除过时的 APIs,例如删除旧的 JSF ManagedBeans 以支持 CDI。所以会有 API 的变化,但我认为这不是什么值得担心的事情。我相信会有一个平滑的升级路径。

预测未来总是很难的。但是,我比大多数人更接近规范团队中的人,所以我可以做出一些有根据的猜测。

  1. EE4J 是 Eclipse 基础生态系统的一部分,因此我确信会有定义明确的规范过程和大量文档。我几乎可以肯定会有详细的规范文档,但我对此持保留态度——我不是内部人士。 (另请参阅上面的更新 - 当前,JavaEE 的规范文档受版权保护,它们似乎不太可能被捐赠给 Eclipse 基金会)。

  2. 据我所知,对MyFaces影响不大。他们只需要遵循不同的规范文档。

  3. 当然可以。 MyFaces 是一个积极开发的项目,旨在成为 Mojarra 的插件替代品。这不会因为参考实现从一家大公司转到 Eclipse 基金会而改变。

  4. 对 PrimeFaces 和 BootsFaces 不会有太大影响。这两个项目都将与 Mojarra 和 MyFaces 以及 JSF 的每个当前版本保持兼容。还有其他 JSF 库,例如依赖于 Mojarra 内部 API 的 HighFaces。不过就算是这种情况,也不会有太大的变化。

无论如何,我预计 JSF API 在不久的将来不会有重大突破性变化(除了清除过时的 API,例如放弃对“ManagedBean”的支持) . Java 世界的优势一直是向后兼容。但同样,这只是一个有根据的猜测,所以请持保留态度。