If you are running a Tomcat project on managed hosting, the best Java runtime is the one that matches your application’s supported Java version, the Tomcat major version you install, and any libraries or frameworks used by your app. In most cases, you should choose the latest Java LTS release that is officially supported by your Tomcat version and your application stack. For many small and medium Java hosting setups, that means Java 17 or Java 21, but the correct choice always depends on compatibility first, not on the newest version alone.
In a hosting environment with Plesk and a private JVM, such as a Tomcat service managed through a panel extension like My App Server, this decision is especially important because the runtime behind Tomcat directly affects startup behavior, servlet compatibility, JSP processing, application performance, and upgrade safety.
What the Java runtime behind Tomcat actually does
Tomcat is a Java servlet container, not the Java runtime itself. The runtime behind Tomcat is the JVM and JRE/JDK version that Tomcat uses to start and run your application. That runtime determines which language features, API levels, and library versions are available to your web app.
When you deploy a WAR file, JSP application, or servlet-based project, Tomcat depends on the JVM for:
- loading the Tomcat server process
- compiling or executing JSP files
- running your application classes and dependencies
- handling memory, garbage collection, and thread execution
- providing the Java API level your app expects
Because of this, choosing the right Java version is just as important as choosing the right Tomcat version. A mismatch can lead to startup errors, unsupported class file versions, dependency failures, or subtle runtime bugs.
The safest rule: match the runtime to the application first
The best practice is simple:
- Check which Java versions your application supports.
- Check which Java versions your Tomcat version supports.
- Choose the newest stable LTS version that is compatible with both.
- Test the application before moving it to production use.
If your app was built years ago, it may rely on older APIs or third-party libraries that do not yet support newer releases. If your app is modern, it may benefit from a current LTS runtime. Do not select Java only because it is the latest available option in your control panel.
Recommended Java versions for Tomcat projects
For most Tomcat hosting scenarios, these are the most common choices:
Java 8
Java 8 remains common in older applications and legacy servlet projects. Use it only if your application, frameworks, or libraries require it. It is still seen in many production environments, but it is no longer the best default for new projects.
Choose Java 8 if:
- your app was developed around Java 8
- older libraries require Java 8 compatibility
- your build pipeline or framework is not ready for newer releases
Java 11
Java 11 is a widely adopted LTS version and a safe choice for many Tomcat applications. It is often the first modern upgrade target after Java 8 because it offers good compatibility and stable long-term support.
Choose Java 11 if:
- your application is compatible with Java 11
- you want a stable LTS runtime for a mature application
- you need a safer upgrade from Java 8 without moving too far ahead
Java 17
Java 17 is a strong default for many current Tomcat projects. It is a modern LTS release and a good balance between compatibility, performance, and long-term support. For new deployments on hosting platforms that support multiple runtimes, Java 17 is often the first version to try.
Choose Java 17 if:
- your application is modern or recently updated
- your libraries support Java 17
- you want a current LTS runtime for Tomcat hosting
Java 21
Java 21 is the newest LTS choice in many environments and is often suitable for new applications and updated frameworks. It can be a very good option if your Tomcat version and dependencies are fully compatible.
Choose Java 21 if:
- your app has been tested on Java 21
- you are starting a new Tomcat project
- your framework documentation explicitly supports it
How Tomcat version affects the Java runtime choice
Tomcat major versions have their own Java requirements. If you install Tomcat through a hosting panel or a service manager, the available Java versions should be checked against the Tomcat release you plan to use.
As a general rule:
- older Tomcat versions usually work with older Java versions
- newer Tomcat versions often require a newer JVM
- the Java runtime must satisfy both Tomcat and your web application
If you are using a control panel workflow such as My App Server in Plesk, you may see several ready-to-install Tomcat and Java combinations. In that case, use the combination that matches your app stack rather than the newest item in the list.
What to check before selecting a runtime behind Tomcat
Before you install or change the Java runtime, review the following points:
1. Application documentation
Check the official documentation for your application, framework, or CMS. Look for the supported Java version, servlet specification, and any restrictions on Tomcat versions.
2. Build tool configuration
If your project uses Maven, Gradle, or another build system, review the source and target compatibility settings. For example, a project compiled for Java 8 will not run correctly on the wrong class file level if the build output or dependencies are not aligned.
3. Third-party dependencies
Libraries may require a specific runtime. This is common with authentication modules, reporting engines, PDF libraries, XML processors, and older enterprise frameworks. Even when your own code is compatible, a dependency may not be.
4. Tomcat release notes
Each Tomcat version has its own compatibility notes. Check the official release documentation to verify supported Java versions before upgrading.
5. Runtime features used by your app
If your application depends on specific JVM features, custom security providers, or newer language features, make sure the runtime supports them fully.
How to choose the right Java runtime in a managed hosting panel
On a managed hosting platform with Plesk and a custom Java extension such as My App Server, the selection process is usually straightforward. You install a Tomcat service, choose a Java runtime, and then deploy your web application package.
A practical workflow is:
- Open your hosting control panel.
- Go to the Java/Tomcat management area.
- Review the available runtime versions.
- Check the Tomcat version that will run with that runtime.
- Select the version supported by your app.
- Deploy a test build first if the app is already in production elsewhere.
If your hosting setup supports both ready-made versions and manual uploads, use the built-in options first when they match your needs. Manual custom runtimes are useful for special compatibility cases, but they should be used only when you know exactly why you need them.
When to use a custom Java runtime
Some Tomcat projects need a non-default Java version. This is usually the case when an application has a strict dependency requirement, when a vendor package was certified only on a particular JDK, or when you need a specific patch level.
A custom runtime may be appropriate when:
- your application requires a version not included in the default list
- you need a specific vendor build of Java
- you are migrating an older application with strict compatibility needs
- you are testing against multiple runtime versions
In a managed Tomcat hosting environment, a custom JVM should still be treated as a compatibility tool, not a default choice. If a standard LTS version works, that is usually the better option for maintainability.
Common compatibility problems caused by the wrong runtime
Choosing the wrong Java version can cause problems that are not always obvious at first. The most common issues include:
- Startup failure: Tomcat does not start because the Java version is too old or too new for the server version.
- Class file version errors: compiled classes were built for a newer Java version than the runtime supports.
- JSP compilation errors: JSPs fail to compile because of runtime or container mismatch.
- Dependency conflicts: libraries require APIs removed or changed in newer Java versions.
- Unexpected behavior: application code works in one Java version but not another due to deprecated features or security defaults.
These issues are often solved by aligning the runtime with the application’s supported version rather than changing application code immediately.
Best practice for new Tomcat projects
If you are starting a new project, the usual recommendation is to choose a current LTS Java runtime that your Tomcat version supports, then build and test against that version from the beginning.
For most new web applications, a modern setup looks like this:
- current supported Tomcat version
- Java 17 or Java 21, depending on app support
- WAR deployment or standard servlet/JSP packaging
- testing in a staging environment before production use
This approach keeps your runtime supportable for longer and reduces the need for urgent upgrades later.
Best practice for existing Tomcat projects
If you already have a running application, do not change the Java version without testing. Even a minor runtime change can affect class loading, security behavior, TLS libraries, and framework compatibility.
Use this migration approach:
- Confirm the current runtime version in use.
- Read the application and framework compatibility notes.
- Create a test copy of the Tomcat service if possible.
- Install the target Java version in the test environment.
- Run application smoke tests, login tests, and key workflows.
- Review logs for warnings and deprecation messages.
- Switch production only after validation.
This is especially useful in hosted environments where Tomcat is managed as a separate service inside a shared account, because you can test the runtime before affecting your live site.
Practical decision guide
If you are unsure which Java runtime to pick, use this simple decision path:
- Application requires Java 8: use Java 8 and verify Tomcat compatibility.
- Application supports Java 11: Java 11 is a safe LTS choice.
- Application supports Java 17: Java 17 is often the best balanced choice.
- Application supports Java 21: use Java 21 if both Tomcat and dependencies are ready.
- No documentation is available: start with the most conservative LTS version supported by your Tomcat release, then test carefully.
In hosting terms, this means: prefer the runtime that your application vendor, framework, or internal build process already supports. Do not make runtime selection a guess.
Using Tomcat in Plesk with My App Server
In a Plesk-based hosting setup with My App Server, you can usually manage Tomcat as a separate service and assign a Java runtime to that service. This gives you more control than a standard file-only web hosting account because your application runs in its own JVM environment.
That is useful for:
- Java hosting for small and medium applications
- Tomcat hosting for WAR-based deployments
- JSP hosting with server-side page compilation
- Servlet hosting for custom web applications
- private JVM hosting with clearer runtime control
This model works well when you need a practical, manageable Java service without the complexity of a full enterprise application server stack.
FAQ
Which Java version is best for Tomcat by default?
For most modern Tomcat projects, Java 17 is a strong default, and Java 21 is also a good choice if your application and Tomcat version support it. For older applications, Java 11 or Java 8 may still be required.
Can I run the newest Java version with any Tomcat version?
No. Tomcat must support the Java version you choose, and your application must support it too. Always check both compatibility layers before upgrading.
Is it better to use a JDK or a JRE behind Tomcat?
In many managed hosting setups, the full JDK is preferred because it provides the tools and runtime components needed for Tomcat administration, JSP compilation, and troubleshooting. The exact package depends on how the hosting platform is configured.
What if my application was built for Java 8?
If the application or its dependencies require Java 8, keep Java 8 unless you have tested and confirmed a safe migration path. Upgrading the runtime without checking dependencies can break the app.
Can I change the Java runtime later?
Yes, but do it carefully. Test the application after every runtime change, especially if you are moving from an older LTS release to a newer one.
Why does Tomcat fail to start after a Java change?
The most common reasons are incompatible class file versions, unsupported Tomcat-Java combinations, or libraries that do not work on the new runtime. Review the startup logs to identify the exact cause.
Conclusion
The right Java runtime behind Tomcat is the one that fits your application, your Tomcat version, and your maintenance plan. For managed hosting and private JVM setups, the safest approach is to choose the newest supported LTS version that your app stack officially supports, then verify it in a test environment before moving to production.
If you are using a Plesk-based Java hosting solution with Tomcat management, such as My App Server, this flexibility makes it easier to match runtime versions to application requirements while keeping deployment and service control practical. When in doubt, start with compatibility documentation, prefer stability over novelty, and test before you switch.