在拉斯维加斯举行的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