SpringOne 会议上讨论了 Java EE 8 延期对 Tomcat 9 的影响

在拉斯维加斯举行的 SpringOne 平台会议上，Mark Thomas（markt@apache.org）给出了 Apache Tomcat 最新的路线图。我们在InfoQ 上曾经关注过Java EE 8 的延期，他指出这件事情同样给Apache Tomcat 团队带来了不少的问题。

Thomas 是 Pivotal 的咨询软件工程师，从 2003 年开始就是 Apache Tomcat 的提交者。他强调，这个演讲阐述的是有关 Tomcat 未来的个人观点，并不代表 Apache 软件基金会或 Pivotal 的观点。

关于路线图，Tomcat 9 将会添加对 Servlet 4.0 的支持。Thomas 说到，“这其实可以分为三类：专家组已经广泛同意的内容、目前正在工作中的内容以及一些将来可能的规划。”

在 Servlet 4.0 已经获得同意的元素方面，将会包含对 HTTP/2 的支持，但是 Thomas 指出，“应用程序本身并不会看到这个特性，应用本身唯一与 HTTP/2 能够产生关联的地方就是推送请求。”这项特性的 API 已经获得了专家组的同意，在 Tomcat 9 中已经实现了。

Servlet 4.0 同时还为监听器（listener）增加了一些默认的 NO-OP 方法，从而减少了我们需要编写的样板式代码。类似的，还引入了 HttpFilter 的抽象基础类，它的功能非常类似于 HttpServlet。Thomas 说“通过它，我们可以在过滤器中直接使用 HttpServletRequest 和 HttpServletResponse，而不必再使用 ServletRequest、ServletResponse 以及额外的类型转换。”

正在讨论的内容包括如何将一个请求映射到当前的 Servlet 上——也就是说，如果它的映射方式使用的是扩展名映射、路径映射和 / 或 URL 中的一部分，那实际上是映射到一个通配符上。这是 JSF 专家组要求了很久的特性，他们所提议的 API 已经在 Tomcat 中实现了，不过有一些微调，目前正在 Jetty 中进行实现。但是，它还没有获得 Servlet 4.0 专家组的同意。

另外两个正在讨论的事情是对请求参数的非阻塞访问，这个特性类似于已经实现的非阻塞读取请求体，它会提供一种机制，允许开发人员以非阻塞的方式从请求体中读取参数；还有对反应型（reactive）的支持，它会是 Spring 5 的一个主题。

Spring 和 Jetty 的工作人员已经开始讨论在 Servlet 容器中实现对反应型的支持。这有望将 Tomcat 社区包含进来，目标是创建一个 Jetty 和 Tomcat 共享的标准 API，应用程序可以使用这个 API。如果专家组能够确定，希望将其添加到 Servlet 4.0 中的话，那么这会是一个很好的起点模型，实现 Servlet 4.0 对反应型 API 的支持。

不过，除此之外，专家组缺乏进展成为了很明显的问题。Thomas 说，对于 Tomcat 支持的其他规范——JSP、统一表达式语言（Unified Expression Language）、 JASPIC （针对容器的 Java 认证服务提供者——实际上是一个可插拔的认证提供者）以及 WebSocket——“则是完全没有任何进展”。

如果说关于 Java EE 8 目前有什么清晰指示的话，那这就是现状了，他们保持了完全的沉默。

JASPIC 至少大致比较稳定和完整。问题更多的是 JSP 和统一表达式语言规范，因为统一表达式语言 3 增加很多新特性，它会影响到 JSP，但是 JSP 并没有进行更新以考虑这些新特性。

一个简单的样例就是在统一表达式语言中，我们现在可以导入类。如果在 JSP 页面中的一段表达式语言里面这样做的话，那么我们所导入的类是否要对这个 JSP 页面可见呢？在 Tomcat 中是这样的，但是关于是否应该如此，规范方面则保持了完全的沉默。

更为重要的是 WebSocket 依然缺乏一个标准的 API 来编写扩展，比如压缩、多路复用等等。在要完成 WebSocket 1.0 的时候，就开始讨论这项功能，但是到现在为止依然没有明显的进展。

从历史上来看，Tomcat 的主发布版本依赖于三项内容：稳定的相关规范、通过 TCK 验证的实现（尽管在 Tomcat 8 中，这一点并不成立），另外，Tomcat 社区相信代码库足够稳定，可以用于生产环境运行。

在 Java EE 8 中，我们所遇到的问题就是所有的事情都毫无进展。我们不知道规范何时能够最终完成。如果今年能够完成的话，我会非常惊讶，如果明年能够完成的话，我会感到非常惊喜，不过，它更有可能要拖到 2018 年才能完成……缺乏最终的规范给我们带来了很多的问题，因为 Tomcat 9 的大量功能已经准备就绪，我们大约在一年前就已经实现了对 HTTP/2 的支持。

在很大程度上，这就是我们引入 Tomcat 8.5 的原因所在。Tomcat 8.5 中的一些新特性也会包含到 Tomcat 9 中，但它们并不是 Java EE 规范的一部分，其中包括对 TLS 支持的一个大范围修改。Tomcat 8.0 允许每个连接器对应一个 TLS 虚拟主机，每个虚拟主机会有一个证书，Tomcat 8.5 及以上支持每个连接器对应多个虚拟主机（通过 SNI 来实现的），每个主机能有多个证书。

不过，这里有个有意思的问题。Servlet 4.0 必须运行在 Java 8 上并且必须要支持 HTTP/2。HTTP/2 需要用到 ALPN （应用层协议协商，Application Layer Protocol Negotiation）和 JSSE ，在 Java 8 中，并不支持 ALPN。

这就意味着我们无法以纯 Java 形式来实现符合该规范的 Servlet 4.0 容器，这是 Tomcat 团队在 18 个月前所遇到的问题。按照 Thomas 的说法，他们要求向下移植（back-port）ALPN，但是遭到了拒绝。

几周前，好像 IBM 的实现也到达了这个功能点，他们向专家组问了同样的问题。我怀疑他们会得到相同的解答。

因此，在目前的 Tomcat 中，ALPN 需要 OpenSSL 来进行加密。Tomcat 对 OpenSSL 进行了包装，使其看起来像一个 JSSE 的实现。

除了对 JASPIC 的支持以外，这包括针对Google OAuth 2 的一个样例配置，Tomcat 8.5 和9 还支持虚拟主机名的通配符匹配、相对HTTP 转发以及大量的其他特性。正在考虑支持的特性包括针对容器的Java 授权协议（Authorisation Contract for Containers，JACC），这是一个与JASPIC 相对应的授权功能。

也有一些特性被放弃了，包括 BIO HTTP 和 BIO AJP 连接器以及对 Comet 的支持，它们在很大程度上已经被 WebSocket 取代了。

尽管 TomEE 已经提供了对 Web Profile 的支持，但是 Tomcat 9 并没有实现 Web Profile 的计划。

InfoQ 今年再次拍摄了 SpringOne 的所有演讲，在未来的几个月中，所有的视频都将会逐步放到我们的站点上。

查看英文原文： Impact of Java EE 8 Hiatus on Tomcat 9 Highlighted at SpringOne