For a Tomcat project, the best Java runtime is the one that matches your application’s Tomcat version, framework requirements, and any libraries your app depends on. In practice, you should choose the lowest Java version that fully supports your application, while still staying within the supported range for your Tomcat release. This reduces upgrade risk and keeps your hosting setup easier to maintain.
In a managed hosting environment with Plesk and My App Server, this choice matters even more because your Java runtime is directly tied to how your Tomcat service starts, how WAR files deploy, and how your JSP or servlet application behaves. If your app is small to medium sized and you want straightforward Java hosting, selecting the correct runtime upfront will save time later.
How to choose the right Java runtime for Tomcat
Tomcat does not run in isolation. It depends on a Java runtime, and the runtime version must be compatible with both:
- the Tomcat major version you install
- the code and dependencies used by your application
The safest approach is to review these three points before deployment:
- Tomcat version — check what Java versions it supports
- Application requirements — check your framework, build tool, and libraries
- Hosting environment — confirm which runtime versions are available in your control panel or custom app server setup
If you are using ITA’s Java hosting with My App Server, you can usually install a ready-made Tomcat and Java combination, or upload and configure a custom version if your project needs something specific.
Recommended rule: use the newest supported runtime your app can handle
A practical rule for Tomcat hosting is to choose the newest Java version that your application and dependencies fully support. This gives you:
- better performance improvements from the JVM
- stronger long-term maintainability
- access to newer language and runtime features
- fewer issues later when the platform is upgraded
However, do not jump to the newest Java release just because it is available. Some older frameworks, libraries, or custom code may still depend on older APIs or behaviour. A runtime that is “new enough” but fully compatible is usually the best option for a Tomcat project.
Tomcat and Java compatibility: what to check
Before you decide which Java runtime to use behind Tomcat, verify the compatibility matrix. Tomcat major versions have different Java requirements. For example, newer Tomcat releases generally require newer Java versions, while older Tomcat releases may still support older runtimes.
Typical compatibility questions
- Does your Tomcat version support the Java version you want to use?
- Does your application need Java 8, Java 11, Java 17, or newer?
- Are you using a framework such as Spring, Struts, JSF, or a custom servlet stack?
- Do any third-party JAR files require an older runtime?
- Are you deploying a WAR file built with a specific target bytecode level?
If you are unsure, check the application documentation first. If the app vendor says “requires Java 11,” do not install only Java 8 even if Tomcat can start with it. The application may deploy but still fail at runtime.
Common Java runtime choices for Tomcat projects
For most Tomcat hosting setups, these Java versions are the ones you will usually consider:
Java 8
Java 8 remains common for older applications and legacy Tomcat projects. It is often the safest choice when:
- the application was built years ago
- libraries have not been updated
- the project was originally developed for Java 8
Use Java 8 only if the application explicitly needs it or has not been validated on a newer runtime. It is suitable for compatibility, but not always the best choice for new projects.
Java 11
Java 11 is a very common middle-ground choice for Tomcat hosting. It is widely supported by many frameworks and gives better long-term support than older versions. It is often a strong option if your project is modern enough to move beyond Java 8 but not yet tied to the latest runtime.
Java 17
Java 17 is a strong choice for current Tomcat projects. It is widely used for new deployments and is often supported by modern frameworks and application builds. If your app is being actively maintained and your libraries support it, Java 17 is often the best balance of stability and modern features.
Java 21 and newer
Newer Java versions can be suitable for current applications, but only if your framework, Tomcat version, and dependencies have been tested with them. This is the right direction for projects that are actively developed and already validated on the new runtime.
For hosting environments that allow selectable runtimes in Plesk or a custom app server, newer Java versions are useful when you want to stay current. Still, test carefully before using them in production.
Which Java runtime should you use for a Tomcat project in the UK?
For a UK Tomcat hosting project, the location is less important than compatibility and maintainability. The best runtime is still the one that matches your app. A practical recommendation is:
- Use Java 17 for most modern Tomcat applications
- Use Java 11 when the app is modern but not yet ready for Java 17
- Use Java 8 only for older or legacy applications that require it
- Use Java 21+ only after confirming full support from your application stack
If you are deploying a new WAR file and have no legacy constraints, Java 17 is often the most sensible default. If you are maintaining an older internal business app, Java 11 or even Java 8 may be the correct choice depending on the codebase.
How My App Server helps with runtime selection
ITA’s My App Server is designed for Java hosting on shared hosting accounts where you need your own Tomcat instance and JVM control without moving to a complex enterprise platform. This is useful for:
- Tomcat hosting
- Java hosting
- JSP hosting
- Servlet hosting
- private JVM hosting for small and medium applications
With this type of setup, you can typically:
- install a prepared Tomcat/Java combination with a button
- select a supported Java runtime version
- run your own Apache Tomcat instance
- manage the service from Plesk
- deploy WAR files and related application resources
- use a separate JVM for your app rather than a shared generic runtime
This makes runtime selection more controlled and practical. Instead of depending on a fixed global Java version, you can align the runtime with your specific application requirements.
Step-by-step: choose the right Java version before deployment
1. Identify your application stack
Start by checking what your app was built with. Look at:
- the application documentation
- the build file, such as Maven or Gradle configuration
- framework compatibility notes
- the release notes for any third-party components
If the app was built with an older bytecode target, that does not always mean it must run on that same version. But it does mean you need to verify runtime compatibility carefully.
2. Check the Tomcat version you plan to use
Different Tomcat branches support different Java releases. Before installing Tomcat, confirm whether your target version is meant for Java 8, Java 11, Java 17, or newer.
If you use a ready-made install option in My App Server, check which Tomcat and Java combinations are offered. If you upload a custom app server, match the runtime manually.
3. Verify framework and library support
Frameworks often determine the runtime choice more than Tomcat itself. For example:
- some older frameworks still prefer Java 8 or Java 11
- modern frameworks often work best with Java 17
- very new framework versions may require the latest supported Java release
Do not assume a library is compatible just because the application starts. Runtime issues may appear under load, during request handling, or when a JSP compiles for the first time.
4. Choose the lowest version that fully supports the app
This is the most reliable approach for hosted Tomcat environments. The lower the runtime version, the fewer surprises you are likely to encounter with legacy code. At the same time, avoid going too low if the application benefits from newer Java support.
5. Test deployment before production use
After selecting the runtime, deploy the application and test:
- Tomcat startup
- WAR deployment
- JSP compilation
- servlet request handling
- database connectivity
- background jobs or scheduled tasks
Also check logs for warnings about deprecated APIs, unsupported JVM arguments, or missing classes. A runtime that starts successfully is not always enough.
Signs you chose the wrong Java runtime
If the Java version behind Tomcat is wrong, the symptoms are often easy to notice. Common signs include:
- Tomcat fails to start
- the WAR deploys but the app returns errors
- you see class version errors
- some JAR files cannot load
- JSP pages fail to compile
- framework initialization errors appear in the logs
A frequent issue is a class file version mismatch. This happens when code was compiled for a newer Java version than the runtime provides. For example, an application built for Java 17 will not run on Java 11.
Best practices for Tomcat and Java runtime selection in hosting
- Prefer supported, documented Java versions only
- Keep Tomcat and Java aligned with the app’s requirements
- Do not mix an old application with a very new runtime without testing
- Use a separate JVM where possible for clearer service control
- Keep the runtime selection documented for future maintenance
- Review logs after each update to catch compatibility issues early
In a managed hosting control panel, good documentation is important. If another administrator later needs to restart the service, rebuild the app, or change the Java version, they should be able to see exactly what is installed and why.
When to use a custom app server version
Sometimes a ready-made Java/Tomcat install is not enough. You may need a custom version if:
- your app depends on a specific Tomcat build
- you need a Java runtime that is not listed in the default install options
- you are migrating an existing project with fixed compatibility requirements
- you want to keep a known-good stack unchanged
My App Server supports custom app server setups for cases like this. That is useful when you need flexibility without moving away from a straightforward hosting control panel workflow.
Examples of practical runtime decisions
Example 1: legacy internal app
An older internal business app runs on Tomcat and uses libraries last updated years ago. The app has only been tested on Java 8. In this case, Java 8 is the safest runtime choice, even if newer versions are available.
Example 2: updated business application
A Java web application built with a modern framework is ready for Tomcat and has been tested on Java 17. Here, Java 17 is a strong default because it offers a modern runtime while remaining widely supported.
Example 3: new development project
A new servlet-based project is being deployed with no legacy dependencies. If the framework and Tomcat version support it, Java 21 may be suitable after validation. If not, Java 17 is often the safer modern option.
FAQ
What Java version should I use for Tomcat by default?
For most modern projects, Java 17 is a good default. It is widely supported and suitable for many current Tomcat applications. If your application requires Java 11 or Java 8, follow that requirement instead.
Can I use Java 8 with Tomcat?
Yes, if your Tomcat version and application support it. Java 8 is still used for older applications, but it is not the best choice for every new project.
Is Java 11 better than Java 8 for Tomcat hosting?
In many cases, yes. Java 11 is newer, better supported, and often a better fit for modern applications. But if your app was built specifically for Java 8, changing without testing can create problems.
Should I always choose the latest Java version available?
No. The latest version is only the right choice if your application, dependencies, and Tomcat release all support it. Compatibility matters more than being current.
What happens if the runtime is too old?
Your application may fail to start, show class version errors, or break during JSP compilation or framework initialization. Some problems only appear after deployment, so testing is important.
Can I change the Java runtime later?
Yes, in many hosting setups you can switch to another supported runtime, especially when using a control panel-based service like My App Server. Still, changing runtime versions should be done carefully and tested before production use.
Do I need a special runtime for JSP hosting or servlet hosting?
You do not usually need a separate kind of runtime, but you do need a compatible Java version behind Tomcat. JSP and servlet applications are especially sensitive to Tomcat and Java compatibility.
Conclusion
For a Tomcat project in the UK, the right Java runtime is the one that matches your application, your Tomcat version, and your dependency stack. In most cases, Java 17 is a solid default for modern applications, Java 11 is a good transitional choice, and Java 8 should be reserved for older projects that require it. The key is to choose the lowest compatible version that fully supports the app and to test the deployment before going live.
With ITA’s My App Server, you can manage Tomcat and the Java runtime directly from a hosting control panel, which makes it easier to align the JVM with your application’s requirements. That is especially useful for small and medium Java applications that need controlled deployment, clear service management, and a private runtime environment.