BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Impact of Java EE 8 Hiatus on Tomcat 9 Highlighted at SpringOne

Impact of Java EE 8 Hiatus on Tomcat 9 Highlighted at SpringOne

This item in japanese

Bookmarks

Mark Thomas (markt@apache.org) gave an update on the Apache Tomcat roadmap on the first day of the SpringOne Platform conference in Las Vegas this week, in which he brought up the fact that ongoing delays to Java EE 8, something we've highlighted on InfoQ before, are also causing problems for the Apache Tomcat team.

Thomas, a consultant software engineer at Pivotal, has been an Apache Tomcat committer since 2003. He stressed that the presentation represents his personal view on the future of Tomcat and is therefore not necessarily representative of the views of either the Apache Software Foundation or Pivotal.

In terms of the roadmap, Tomcat 9 will add support for Servlet 4.0. "Really this falls into three categories: the stuff the expert group has already broadly agreed, the stuff it is sort of working on, and some possible future plans," Thomas said.

In terms of the agreed elements of Servlet 4.0 HTTP/2 support will be included, though Thomas pointed out that "the application isn’t going to see it. Really the only place the application will get involved with HTTP/2 is on push requests." The API for this has been agreed by the expert group and has been implemented already in Tomcat 9.

Servlet 4.0 also includes a number of default NO-OP methods for listeners to reduce the amount of boiler-plate code you need to write. Along similar lines, an Abstract Base class for HttpFilter has been introduced which is a direct counterpart to HttpServlet. "It’s there so you can work with HttpServletRequest [and] HttpServletResponse in your filter rather than having to work with ServletRequest, ServletResponse and casting," Thomas said.

Under discussion is access to how a request was mapped to the current Servlet - i.e if it mapped using extension mapping, path mapping, and/or which part of the URL actually matched to the wildcard in that mapping. This is something that the JSF expert group have wanted for some time, and they have proposed an API which has been implemented in Tomcat with some tweaks, and is currently being implemented in Jetty. It hasn't yet been agreed by the Servlet 4.0 expert group, however.

Two other things under discussion are non-blocking access to request parameters, which would be similar to how you can already do a non-blocking read of the request body and would provide a mechanism by which a developer would be able to read parameters from a request body in a non-blocking way; and reactive support, which is a major theme of Spring 5.

Spring and the Jetty folks started a discussion for having Reactive support in a servlet container. That should hopefully be expanded to include the Tomcat community and the aim is to have a standard API shared between Jetty and Tomcat that applications can use…If the expert group decide that they want this in Servlet 4.0, this gives us a good starting model for putting the reactive APIs into Servlet 4.0 as well.

Beyond that however, lack of progress from the Expert Group becomes very apparent.  With regards the other specification that Tomcat supports- JSP, Unified Expression Language, JASPIC (Java Authentication Service Provider Interface for Containers - essentially pluggable authentication providers), and Web Socket - "absolutely nothing has happened," Thomas said.

If there was ever a clear indication of what is happening with Java EE 8 at the moment, then this is probably it. They have been totally silent.

JASPIC is at least broadly stable and complete. More problematic are the JSP and Unified Expression Language specs since Unified Expression Language 3 added a number of features that impacted on JSPs, but the JSP spec wasn't updated to take account of them.

A simple example is that in Unified Expression Language you can now import classes. If you do that in a piece of Expression Language on a JSP page, does the class you import become visible to the JSP page or not? It does in Tomcat, but the spec is utterly silent on whether it should or whether it shouldn’t.

More critical still is WebSocket which lacks a standard API for writing extensions for things like compression, multiplexing and so on. This was something that was being talked about towards the end of the work on WebSocket 1.0, but there hasn’t been much discernible progress since.

Historically, major releases of Tomcat have depended on three things: the relevant specifications being stable, the implementation having passed the TCK (although that wasn’t true with Tomcat 8), and the Tomcat community believing that the code base is stable enough for it to be run in production.

The problem we have with Java EE 8 is that nothing is happening. We don’t know when the specs are going to be finalised. I’d be amazed if it is this year, I’d be surprised if it is next year; it’s probably going to be more like 2018…This lack of a final specification has been causing us problems since large chunks of Tomcat 9 are ready to go; we’ve had HTTP/2 support for about a year now.

This broadly is why Tomcat 8.5 was introduced. New features in Tomcat 8.5 that are also in 9 and are not part of the Java EE specification include a major overhaul of TLS support. Tomcat 8.0 allowed one TLS virtual host with one certificate per connector. Tomcat 8.5 and up includes support for multiple virtual hosts per connector (implemented via SNI), with multiple certificates per host.

There is however an interesting wrinkle here. Servlet 4.0 must run on Java 8 and must support HTTP/2. HTTP/2 requires ALPN (Application Layer Protocol Negotiation) and JSSE, in Java 8, doesn’t support ALPN.

What this means is that you can’t actually implement Servlet 4.0 to the specification in a pure Java form, a problem that the Tomcat team encountered some 18 months ago. They asked to back-port ALPN but were refused, according to Thomas.

A couple of weeks ago IBM presumably got to the same point with their implementation and have just asked the same question of the expert group. I suspect they are going to get the same answer.

In Tomcat as it stands therefore, ALPN requires OpenSSL to do the encryption. The Tomcat team have wrapped OpenSSL to look like a JSSE implementation.

As well as JASPIC support, including an example configuration for Google OAuth 2, Tomcat 8.5 and 9 will get wild card support for virtual host names, support for relative HTTP redirects, and a large number of other features. Under consideration is support for Java Authorisation Contract for Containers (JACC) - the authorisation counterpart to JASPIC.

Some features have also been dropped. These include the BIO HTTP and BIO AJP connectors along with Comet support, which has been largely superseded by WebSocket.

There are no plans to implement the Web Profile for Tomcat 9, although this is offered by TomEE.

InfoQ is filming all the sessions at SpringOne again this year, and all videos will be made available on the site over the coming months.

Rate this Article

Adoption
Style

BT