Java 7 has recently been released, and Apache Tomcat 8 project has just opened for development. It begs the question – are they related?
In short, not necessarily. We create a new major version of Tomcat when there are new versions of three specifications—Servlet, JavaServer Pages (JSP) and Expression Language (EL). Minor updates (maintenance releases) do sometimes get produced but major changes to all three specifications are released together as part of the J2EE specification. Once a new version of the J2EE specification is released, this is what governs the update to the next major version of Apache Tomcat, and it will implement the new features defined within these specifications.
For Tomcat 6, the defining specifications are the Servlet 2.5; JSP 2.1 and EL 2.1 specifications and for Tomcat 7 they are Servlet 3.0; JSP 2.2 and EL 2.2. Work on the Servlet 3.1 and EL 3.0 specifications is underway, and it is expected that there will be a new version of the JSP specification although I haven't seen any indication of work in that area yet. If the changes in JSP 2.2 are anything to go by, any changes in the JSP specification are likely to be minimal and will probably happen closer to the J2EE release. In terms of Java 7 support, Tomcat 8 will require the minimum Java version specified by the Servlet 3.1 specification. At the moment, I expect that that will be Java 7 but we won't know for sure until the specification is finalized.
As the work on the specifications proceeds (I am on the expert group for both Servlet 3.1 and EL 3.0) and the changes firm up then those changes will be implemented in the Tomcat 8 branch. So far, Tomcat 8 specific changes have been limited to re-factorings that change some of the internal APIs and therefore have not been back-ported to Tomcat 7 since we don't want to change APIs there unless we have to. Current ideas for what features (other than the specification changes) might be included in Tomcat 8 can be found in svn along with the Tomcat 8 specific changes so far.
That all depends on when the next Java EE specification is finalized. Since the specifications are still in the very early stages, it should be expected that the first stable Tomcat 8 is at least a year or perhaps even longer off. That said, there is always the possibility of alpha and beta releases before the specifications are finalized. You can see by looking at the history of major releases that it is typical for these projects to be multi-year tasks:
At the moment, you can use Java 7 with Servlets. You can use it with JSPs as long as you configure the JSP Engine to use javac as the compiler. By default, the JSP Engine is pre-configured to use the Eclipse compiler and the current version does not support Java 7. Note that I haven't actually tested using javac with JSPs that use Java 7. It should work, but if it doesn't, ask on the users list. As soon as Eclipse release a compiler that supports Java 7, Tomcat will be updated to use it.
You'll be able to write Servlets and JSPs that use Java 7 but be aware that the specification states Java 6 is the minimum version so you might have portability issues. If Java 7 follows the pattern of previous releases, there should be a noticeable performance improvement using Java 7 over Java 6. As with anything performance related, you'll have to test it in your environment to see what the actual effect is.
Java 7 is still in its first release, and no performance tests have been made on Tomcat 7 as of yet. Also, there has been at least one high profile bug in an Apache project, an issue with the Lucene project that Java 7 caused problems with index corruption and crashing. I have also noticed some SSL issues when using Java 7 with CLIENT-CERT authentication that I haven't had a chance to dig into yet. While certainly we can expect bugs like this to be fixed and performance to improve in the long run, before Tomcat 8 is available, it is recommended that you stay away from Java 7 in production for a little while longer, or that if you do embrace it, be sure to do extensive testing before releasing any mission-critical applications.