Just about one month ago, Java 7 was released. The official project was opened by the Apache Software Foundation for its open source JSP and servlet container - Apache Tomcat. Since Java 7 is the latest version, many users are wondering if Tomcat 8 will support Java 7, or even if they should use it in Tomcat 7.
 
Mark Thomas, SpringSource engineer and ASF release manager for Tomcat 7 explains in a post this week how the two relate.

In short: it has yet to be determined if Java 7 will be part of Tomcat 8, and while Tomcat 7 will never officially support Java 7, there are work arounds to getting it to work, but right now you should hold off on using Java 7 in production with Tomcat 7.

How Will It Be Decided If Java 7 is in Tomcat 8?

Within the J2EE specification, which governs Tomcat's official direction, there are three specifications that need to be made: Servlet, JavaServer Pages (JSP) and Expression Language (EL).  Once a new version of the J2EE specification is released, the next major version of Apache Tomcat is updated. Apache Tomcat 8 will require the minimum Java version specified by the Servlet specification. The hope is for that to be Java 7, but nothing will be for certain until the specification is finalized.

What Will Java 7 Give Tomcat 7 Users?

Thomas explains in his post the basics, that you will be able to write Servlets and JSPs - however any new features (which he couldn't think of many cases where it would affect these pieces), you may encounter portability issues. He also warns:

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.

Should I Use Java 7 Now?

While eager to jump into the Java 7 community, it should be noted that in its first release there has been at least one high profile bug in the Apache product (please refer to the Lucene project) and Java 7 causing problems with crashing. Thomas also gives other examples of issues he has noticed with Java 7, explaining:

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.

Don’t expect Apache Tomcat 8 to be ready for release over night. With the specifications still in the very early stages, Tomcat 8 is slated for its first stable release next year, or maybe even longer. For more information and to read the entire blog post, click here.

I don't know how JEE 7 is tracking, but with Java 8 rumored to be "just around the corner", they should wait for Java 8. Java 6 has been around a long time, but it's clear that even then, Java 7 was rushed out. Just the fact that there is supposed to be only a year between 7 and 8 highlights that.

Everyone wanted the successor to Java 6, noone wanted to wait 5-6 years for it, but at the same time, no one wants a new Java every year either.

So, basically, I consider Java 7 an interim release. By the time it actually gets rolled out and even contemplated for use in production, Java 8 will be knocking on the door, starting the whole process over again.

If there's any expectation that Java 8 will be around for 2-3 years, then they should simply wait for it and let folks standardize around something with more of a lifespan than what Java 7 will likely have.

Java 7 is an evolutionary update, it is straightforward for most apps to update and provides numerous benefits.  The IDE and tools ecosystem are being quick to add support.  Java 8 on the other hand will be 'revolutionary', addiing features (modules, closures) which will take longer to get everything in the ecosystem to support.  

Everyone wanted the successor to Java 6, noone wanted to wait 5-6 years for it, but at the same time, no one wants a new Java every year either.

So, basically, I consider Java 7 an interim release. By the time it actually gets rolled out and even contemplated for use in production, Java 8 will be knocking on the door, starting the whole process over again.

I'm fine with new java every year as long as it is backward-compatible. Companies may choose to (or not to) upgrade to the most recent version, considering benefits and effort involved.