Java 7（包括SE和EE）方面的工作开展得怎样？ 我们参与了Java EE 7和SE的执行委员会。我们参与了最近的Java EE 7发布。就Java SE 7而言，我们是其专家小组成员。我们发表了自己的看法，确保自己是社区进程的一分子。除了甲骨文外，我们是OpenJDK的第一大贡献者。我们有不少的人员专门从事OpenJDK的开发。大概四五年前，我们就有了符合测试兼容包（TCK）的Java，我们把它与红帽企业Linux一并交付。我们打算继续保持这个传统；我们全力支持OpenJDK。我认为，充满不确定性的是甲骨文在OpenJDK之后有什么动作。 甲骨文可能会使用Hotspot和Jrockit，封装基于OpenJDK的另一个发行版。它会在这个环境加入什么类型的附件？从市场的角度来看，甲骨文表示自己希望在Java的基础上提供增值服务。不过我认为，甲骨文会何去何从并不明朗。我们希望确保规范本身和参考实现很好、很成熟，而且拥有市场中的每个人都需要的所有基本功能。 可以说说Apache基金会围绕TCK许可条款与甲骨文之间的争端吗？ 到目前为止，双方对此显得有点沉默。SE 7果真发布时，双方并没有披露新TCK的所有许可条款。我们希望他们继续心怀善意。到目前为止，他们在社区进程方面一直很开放，我们只能静观其变。 2007年，甲骨文曾发表了好多文章和博文，介绍JCP及其运作方式。只是笼统地讲述了一些最佳实践应该怎么样。就实现自己的既定目标而言，甲骨文在过去的脚步似乎有点慢。与此同时，甲骨文却加快发布了新规范的步伐。Java SE 7有一个新规范，EE 7也有一个新规范，还准备为SE 8和EE 8发布新规范。我认为，大家都抱着乐观的态度。 你们在如何应对其他语言在JVM上运行的趋势？ 我们有一项名为自由选择（Open Choice）的战略。该战略的初衷是，能够接受任何基于JVM的技术——或者不是基于JVM的一些技术，而且能确保你拥有的运行时环境采用了许多不同的语言和组件模型。我们可以针对Struts或Spring，运行任何通过认证的框架。Ruby on Rails可以在JBoss上运行。借助OSGi之类的组件模型，你可以用OSGi来设计整个应用程序，可以构建OSGi绑定包（OSGi bundle）；我们会接受并使用所有这些绑定包。我们在关注所有那些语言，为它们提供支持，并提供认证。我们说，你仍需要运行时环境；你仍需要容器和服务，而不是为每种语言和每个框架从事重复性工作。要是有一大堆环境，你最后可能有五六种平台。至于哪些语言和哪些模型最适合自己，我们留给开发人员去定夺；但你总是会有同样的运行时环境和同样的服务。 一些厂商支持几个不同的环境。VMware等另一些厂商则不然，他们说就支持Spring和 Groovy。我们积极接受环境的多样化。 Seam方面情况怎么样？ Seam的情况非常好。它已成为Java EE 6的上下文和依赖注入（CDI）规范JSR 299。它其实是一种更现代化的框架。它也是六年前Spring着手要解决的问题，当时Spring在Java EE方面遇到了困难。我们最终绕了个大圈子，回到原处：Java EE借助一种更现代化的框架（即CDI），结合了其中一些概念。 Seam的开发者Gavin King也一直在尝试一些新语言。Ceylon采用了Seam的部分概念，结果变成了一种语言。也许，有人会拿它与Scala作比较，但是与Gavin交流一番，就明白Seam的目的并不是用来取代其中一些更新的语言和语言类型。外界一直问我们在如何对待Seam？我们奉行的宗旨是，开源的一部分就在于大量的研究开发和试验。我们就是想看看Gavin开发的东西是不是让人们有兴趣。 JBoss接下来会怎样？ 我们正在做的工作就是，不断完善这个应用平台，而这方面的根本体现在Java EE6中。这个微服务容器已成为我们开展的一切工作的基础。我们开始不单单着眼于整体式应用服务器，而是关注应用程序的基本结构。你有一种占用资源非常少的平台，可以在iPhone和可插接电脑之类的一些设备（移动性很强的设备）上运行，不过该环境支持HTML 5和不同的客户端。这种平台具有动态性，你可以即插即用服务。我们在关注自我扩展和自我愈合功能。它是策略驱动型的平台，可以减少大量的人工干预。这就是我们在这方面（注：JBoss）的前进方向。 大家可以开始看到产品组合有不一样的功能。独立式的企业服务总线（ESB）或规则管理系统已成为基本结构的一部分。这是今后几年的长远目标。就短期而言，红帽很有希望成为云计算领域的一大玩家。我们提供了所有部分。我们有内核虚拟机（KVM）、操作系统、中间件的所有组件、平台运行时环境以及服务和组件。我们运用到了所有这一切。 |
