Java 6 End of Life Impact for Apache Tomcat Users

posted by mthomas on January 30, 2013 09:08 AM

There has been some discussion on various forums and mailing lists about the End of Life for Java 6 and what it means for Apache Tomcat users. In response to these questions, we have put together this article that aims to summarize the key questions and give you some of the background and answers you need to plan how to best handle this transition in your deployments.

Here is a quick summary: If you want to run a supported version of Java—one with updates for bugs and security issues—then you will need to upgrade to Java 7. If this isn’t an option, you will have to purchase some form of support contract. Generally, upgrading to Java 7 will be the better long term option but the right decision for your business will depend on your circumstances.

What about Tomcat and Java—where are the risks?

For every Tomcat release, the formal build and testing is performed on the latest release of the minimum Java version required by the relevant specification. That means that the Tomcat 6 releases are built and tested with the latest Java 5 update and that the Tomcat 7 releases are built with the latest Java 6 update. There are also several continuous integration systems building and testing Tomcat with a variety of Java versions as well as all the local testing that the committers perform. In addition to all of this testing, the Apache Software Foundation (ASF) runs a number of services on Apache Tomcat—again using a variety of Java versions including the ASF Jira instance that runs on Java 7 and Tomcat 7. While I can recall several issues with running Tomcat on older, unsupported Java versions, I cannot recall a single reported problem that was traced to running Tomcat on a newer version of Java. Running Tomcat 6 or Tomcat 7 on Java 7 is very low risk.

For systems currently running reliably on Java 6 there is no immediate risk. The most likely thing to increase the risk of continuing to run on Java 6 is a security vulnerability. Not all Java security vulnerabilities impact server-side Java. The chances of being impacted by a Java security vulnerability are greater if the security manager is used as a number of vulnerabilities are related to ways to bypass the security manager. If a security vulnerability is announced in Java 6 that impacts your Tomcat deployment after Java 6 EOL has passed then upgrading to a new Java 6 release will not be an option unless you have purchased a support contract. It is likely to be lower risk to start the process of upgrading to Java 7 now rather than having to react at short notice to a vulnerability announcement.

Since the Java 5 EOL, there has been at least one case where a Java bug was identified that affected Apache Tomcat and, because of Java 5 had reached EOL, the bug was not fixed in Java 5. Rather than provide a workaround for this bug, the Tomcat developer community required users affected by this bug to upgrade to a newer Java version where the bug had already been fixed. The decision to provide a workaround or not depends on many factors including the severity of the bug, the number of users affected and the invasiveness of implementing the work-around. While there are no known issues with Tomcat and Java 6 at the moment, it is certainly possible that an issue may arise in the future and that the Tomcat developer community opts to require an upgrade to Java 7 to resolve the issue.

So, knowing that if you are on an unsupported version of Java and that there are circumstances that could occur that where you would be forced to take action to upgrade to Java 7, it’s better to plan an upgrade sooner than later. However, you are probably ok in the short term.

Will any support for Java 6 and Tomcat be expected?

Supported versions of Tomcat (currently 6.0.x and 7.0.x) are supported by the Tomcat community running on any Java version that version of Tomcat is designed for so Tomcat 6 is supported on Java 5 and higher and Tomcat 7 is supported on Java 6 and higher.

Should you encounter an issue where the root cause is a Java bug then, as described above, the Tomcat community may provide a workaround for the bug in Tomcat. If the Tomcat community elects not to provide a workaround then, in addition to upgrading to a newer version of Java, there is the option of purchasing support for your older version of Java and obtaining a fix from you JRE vendor. There is also the option to pay for commercial support for Tomcat from vendors like VMware. VMware recently announced that it will continue to provide commercial support for Java 6 for Apache Tomcat and its tc Server distribution. This does not mean that VMware will address fixes in Java 6 itself, but it will provide workarounds for Tomcat and tc Server.

How are Java upgrades going?

Experience to date is that upgrading to Java 7 is a smooth and painless process. In theory, web applications written using Java 6 should run the exact same way on Java 6 or 7. One thing to watch out for is to make sure you do not compile your application using a newer version of Java than is used by the application server. However, if an application directly accesses the internal classes of the JRE (e.g. something from the sun.* packages) then a Java upgrade may be more difficult and require changes to the application. If you are just using the standard public Java API, you should be fine. Of course, you should test your application on Java 7 before upgrading the live deployment.

How does Tomcat’s Versions and Upgrades work?

Two years ago, we published a post discussing the beginning of work on Tomcat 8. In it, we explained how the Tomcat community approaches support for versions. In short, at any time the Tomcat community supports 3 major version of Tomcat. Tomcat 8 is well under development and should be released later this year. As such, the community is actively working on just Tomcat 6, 7 and 8 right now.

The change in support is intentionally not a quick transition, as we try to give users adequate time to upgrade. Only once Tomcat 8 began active work did the community announce the End of Life for Tomcat 5.5, giving users at least 12 months to prepare for phasing out support. Support for Tomcat 5.5 was discontinued last fall, and finally removed from the website entirely in January of this year, nearly 16 months after the initial announcement. Documentation is still there and available from Apache archives. However, if a user reports a bug in Tomcat 5, we will suggest an upgrade to Tomcat 6 and look at the bug there. Tomcat 5 bugs are not going to be fixed from this point forward.

When will Tomcat 6 End of Life?

In trying to figure out how much longer Tomcat 6 will be supported, it is important to recognize that major versions of Tomcat are tied to major versions of the Java EE specification. Tomcat 8 is being developed and should be released later this year after Java EE 7 is finalized. Tomcat 9 will be aligned with Java EE 8 and that is a number of years away. Since the community supports 3 versions at any time, Tomcat 6 will continue to be supported until Tomcat 9 becomes active, so we should expect at least another two to three years of active support and development on Tomcat 6.

Upgrading Tomcat

For anyone upgrading Tomcat, there are various tools and migration documents on the Apache website including a list of the significant changes by major version. We highly recommend that you always start with a clean install and apply configuration changes you need. Don’t try to use earlier configuration files—they might work, but we also change, add, and remove default settings at times. So, it’s best to start with a clean install.

The general rule is—if something works on Tomcat 6, it should work on Tomcat 7. The only change I think you might see is in the additional scanning of web applications required by Servlet 3.0 that can lead to longer start times. To avoid this you need to do things. First add metadata-complete=true to your application’s main web.xml file and also add an empty absolute ordering element (i.e. < absolute-ordering >).

Other than that, an upgrade problem is either due to a Tomcat bug (unlikely) or a dependency on a Tomcat interface that has changed. These are all covered in detail in the migration guide. For example, if you have a custom realm or context, you would want to look at the guide. If you have an application written to the Servlet/JSP/EL specifications, it should just work.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.


Since the Java 5 EOL, there

Since the Java 5 EOL, there has been at least one case where a Java bug was identified that affected Apache Tomcat and, because of Java 5 had reached EOL, the bug was not fixed in Java 5. Rather than provide a workaround for this bug, the Tomcat developer community required users affected by this bug to upgrade to a newer Java version where the bug had already been fixed.

Post new comment

This question is for testing whether you are a human visitor and to prevent automated spam submissions.