When you host a Java application on Tomcat, the runtime behind Tomcat matters just as much as the Tomcat version itself. A newer Java runtime can improve security, performance, and long-term support, but an older runtime may still be required by an application that was built for a specific framework, library, or application server setup. In a managed hosting environment, the safest choice is the one that matches your application’s documented requirements while leaving enough room for future updates.
For Tomcat hosting in the UK, this usually means balancing compatibility, maintenance overhead, and the way your hosting control panel manages the service. If you are using a Plesk-based Java hosting solution such as a private JVM or a custom Tomcat instance through My App Server, you can often choose from several ready-made Java/Tomcat combinations or upload and configure a custom runtime manually. That flexibility is useful, but it also makes version choice an important decision.
Why the Java runtime behind Tomcat matters
Tomcat is the servlet container, but the Java runtime is the execution layer that actually runs your application code. Your application may start successfully on one runtime and fail on another because of:
- removed or deprecated Java APIs
- changes in TLS and certificate handling
- module system restrictions in newer Java releases
- different garbage collection behaviour and memory usage
- library compatibility with specific Java versions
- framework requirements such as Spring, Hibernate, Struts, or older JSP tag libraries
In practical hosting terms, this means the “best” runtime is not always the newest one. The correct runtime is the one your application can run on reliably, with acceptable support and security standards.
Older versus newer Java runtimes: what changes in practice
When an older runtime can be the safer choice
An older Java runtime may be appropriate when the application was built and tested against it, and when upgrading would require code changes or third-party library replacements. This is common with legacy JSP/Servlet applications, older WAR deployments, or applications that depend on libraries that have not yet been certified on the latest runtime.
Choose an older runtime only when you have a clear reason, for example:
- your application vendor specifies a minimum and maximum Java version
- the application uses older dependencies that do not support newer Java releases
- you need a stable environment for an inherited application that has not been refactored yet
- the application is sensitive to runtime changes and has already been validated on that version
Older runtimes may be easier for legacy software, but they usually come with higher maintenance risk. Security updates may be limited, and some older combinations are less suitable for long-term hosting.
When a newer runtime is usually the better option
A newer Java runtime is generally the preferred choice if your application supports it. It often gives you:
- better security defaults
- longer support life
- performance improvements
- better compatibility with current frameworks and libraries
- simpler future upgrades
If you are deploying a new application, the best practice is to build and test on a supported modern Java version rather than starting with an older release. This reduces the chance that you will need a disruptive migration later.
How to decide which Java version to use with Tomcat
The right decision is usually based on application requirements, not personal preference. Use the following checks before selecting a runtime behind Tomcat.
1. Check the application documentation first
Start with the most reliable source: the application or framework documentation. Look for:
- supported Java versions
- supported Tomcat versions
- required JSP/Servlet specifications
- known issues with specific Java releases
- required JVM options or startup flags
If the vendor says the application supports Java 11 through Java 17, for example, it is usually better to pick the newest supported version that has also been tested by your team.
2. Review your libraries and build tools
Even if the application source code looks compatible, one older dependency can block a runtime upgrade. Check the full stack, including:
- build tools such as Maven or Gradle
- application frameworks
- database drivers
- logging libraries
- XML, JSON, and mail libraries
- any custom JAR files included in the deployment
Java runtime changes often affect transitive dependencies, so testing the full WAR file is more useful than testing only a small code sample.
3. Match the runtime to your hosting model
In a shared hosting account with a private JVM or custom Tomcat instance, the runtime version must fit within the resources and management model provided by the control panel. With My App Server in Plesk, you can typically manage Tomcat, JVM settings, and application deployment without needing full server administration access.
This is useful for small and medium Java hosting setups because you can:
- select a ready-made Java/Tomcat combination where available
- install a separate Tomcat instance for one application
- keep the Java runtime isolated from other apps in the same account
- adjust service settings without affecting unrelated websites
That said, if your application needs complex clustering, enterprise-level session replication, or dedicated application server management, a standard managed hosting Tomcat setup may not be the right fit.
4. Consider support life and security
From a hosting perspective, a runtime should not only “work” but also remain supportable. Newer Java releases usually receive updates for longer, which is important for any application exposed to the internet. If two runtimes both work, choose the one with the stronger support horizon unless your application specifically requires the older one.
This is especially relevant for UK businesses that want predictable maintenance and minimal downtime. Fewer emergency upgrades usually mean a lower support burden and more stable hosting operations.
Recommended selection strategy for Tomcat hosting
A practical rule is:
- Use the newest runtime officially supported by the application.
- If the application is legacy, use the newest runtime that it has already been tested against.
- If you are unsure, test in staging before changing production.
- Keep the runtime consistent across development, staging, and live hosting where possible.
This approach reduces surprises when deploying WAR files or updating dependencies. It also makes support easier because the environment is more predictable.
Typical compatibility patterns
Legacy JSP and servlet applications
Older JSP/Servlet applications often depend on an older Java runtime and an older Tomcat branch. They may still run on a newer Java version, but compatibility should not be assumed. Check whether the app uses deprecated APIs, old tag libraries, or hardcoded assumptions about the JDK.
Modern Spring-based applications
Modern Spring applications usually benefit from newer Java versions, especially if they are actively maintained. In many cases, they run better on current LTS releases and are easier to support over time. If you are deploying a newer WAR to Tomcat, newer Java is often the sensible default, provided the framework version supports it.
Custom in-house applications
For in-house systems, the most important factor is repeatability. If the application has grown over time and different developers have used different JDKs, standardise the runtime before migration. A clear baseline is better than guessing which version “might” work.
How to test before switching the runtime
Changing the Java version behind Tomcat should be treated as a controlled update, especially for a live hosted service. Use a test copy of the application if possible.
Practical testing checklist
- deploy the WAR file to a staging Tomcat instance
- start Tomcat and confirm the service comes up cleanly
- check logs for warnings, class loading errors, or unsupported API calls
- test login, forms, file uploads, and database access
- verify external integrations such as email, payment gateways, or APIs
- test scheduled tasks if the app uses them
- confirm response times and memory usage are acceptable
If the application fails, the log output usually shows whether the problem is caused by a missing class, a deprecated JVM option, or a library incompatibility. This is much easier to resolve before a production cutover.
Watch for common runtime upgrade issues
Common problems when moving to a newer Java runtime include:
- illegal reflective access warnings or failures
- removed Java EE modules that older applications expected to find in the JDK
- changes to TLS defaults that affect outbound connections
- outdated startup flags no longer accepted by the JVM
- memory settings that were suitable for the old runtime but not the new one
These issues are not necessarily blockers, but they should be checked before you switch the live environment.
Using My App Server in Plesk to manage Java and Tomcat versions
If your hosting account includes My App Server, version choice is usually more manageable because the service is designed for private JVM and Tomcat hosting within a control panel workflow. This is helpful when you want a separate Java runtime for one application without affecting the rest of the account.
In a typical setup, you can:
- install a Tomcat instance from ready-made options where available
- upload or configure a custom app server if you need a specific runtime
- start, stop, and restart the service from Plesk
- adjust service settings in one place
- deploy WAR or JSP-based applications more simply than on a fully manual server build
This is especially useful for hosted JSP, servlet, and small-to-medium Java applications where you want control without managing the full operating system stack.
When to use a ready-made version
Use a preconfigured Java/Tomcat version when your application fits one of the supported combinations and you want the simplest deployment path. This is often the best option for new installs, standard frameworks, or applications with clear version requirements.
When to upload or configure a custom runtime
A custom runtime is appropriate when you need a version that is not included in the standard install choices, or when your application has a precise compatibility requirement. In that case, verify the runtime carefully and document the settings you use so the environment can be maintained consistently.
Best practices for choosing between old and new Java runtime versions
- Prefer the newest supported version that your application has been tested with.
- Do not upgrade a live Tomcat instance without checking logs and compatibility first.
- Keep staging and production aligned as closely as possible.
- Document the exact Java version, Tomcat version, and JVM options in use.
- Review runtime support status regularly, especially for long-lived hosted applications.
- Use separate instances for apps with different version requirements.
In a managed hosting environment, consistency matters. A well-documented setup reduces support time and helps avoid accidental breakage during updates.
Common scenarios and what to choose
You are hosting a new application
Choose a modern supported Java runtime that the framework officially supports. If multiple supported versions exist, pick the latest stable one you have tested successfully.
You are moving an older WAR to Tomcat hosting
Start with the Java version used by the application previously, then test whether it can move to a newer release. Only upgrade after confirming the app, dependencies, and startup flags all work correctly.
You need to support both old and new applications
Use separate Tomcat instances or separate Java runtime setups if the hosting platform allows it. This avoids forcing one compromise version on every application.
You are not sure which version is compatible
Check vendor documentation, review dependency requirements, and test in a staging environment. If you still cannot confirm compatibility, the safer short-term option is usually the last known working runtime.
FAQ
Is the newest Java version always the best choice for Tomcat?
No. The newest version is only the best choice if your application and libraries support it. Compatibility comes first, then support life and security.
Can I run an older Java application on a newer Tomcat instance?
Sometimes yes, but not always. Tomcat and Java both have compatibility limits, and older applications may depend on removed APIs or outdated libraries. Test before changing production.
What is the advantage of a private JVM in hosting?
A private JVM gives your application its own runtime environment. That makes it easier to choose a Java version, isolate the app, and avoid conflicts with other hosted services in the same account.
Should I match the Java version used in development?
Yes, if possible. Matching development, staging, and production reduces deployment issues. If production must differ, document the difference clearly and test thoroughly.
What should I do if my app needs an unsupported Java version?
If the version is still required by the application, use the closest safe setup available and plan an upgrade path. For custom or manually configured app servers, verify that the runtime can still be managed reliably through your hosting environment.
Does Tomcat version choice affect Java runtime choice?
Yes. Tomcat and Java compatibility are linked. A newer Tomcat version may require a newer Java runtime, and older Tomcat releases may not work well with the latest Java versions. Always check both sides of the matrix.
Conclusion
Choosing between an older and newer Java runtime behind Tomcat is mainly a compatibility decision. For Tomcat hosting in the UK, the best result usually comes from using the newest runtime your application officially supports, while keeping a fallback plan for legacy applications that have not yet been updated. In a Plesk-based hosting setup with My App Server, this process is easier because you can manage a private JVM, install Tomcat, and control the service from one place.
If your application is new, aim for a modern supported Java release. If it is legacy, validate the current runtime carefully before upgrading. In both cases, test on staging, review logs, and keep the configuration documented. That approach gives you a stable Tomcat hosting environment with fewer surprises during deployment and maintenance.