Choosing the right Java runtime for a project in the UK depends on two things: what your application needs today, and how much compatibility risk you want to carry into the future. In a hosting environment, the runtime version affects whether your app starts correctly, which libraries it can use, and how easily you can manage updates through your control panel. If you are deploying Java web applications, JSP, servlets, or a WAR package on a shared hosting account with a private JVM, the safest approach is to match the runtime to the framework and build requirements first, then choose the newest supported version that your application has been tested with.
For most UK projects hosted on a managed platform with Plesk and a Java app server extension such as My App Server, the practical rule is simple: use the version your app was built and tested for, unless you have a clear reason to move to a newer LTS release. If you are starting a new application, choose a current LTS version such as Java 17 or Java 21 where your frameworks and libraries support it. If you are maintaining an older application, you may need Java 8, Java 11, or Java 17 depending on framework compatibility and third-party dependencies.
What “Java runtime” means in hosting
The Java runtime is the environment that runs your application. In hosting terms, it is the JVM and related libraries that execute your Tomcat, servlet, or JSP application. The runtime version is important because Java is backward compatible only to a point: a newer runtime can often run older code, but code compiled for a newer release will not run on an older runtime.
When you host Java apps through a control panel like Plesk, the runtime choice is often tied to the app server installation. With a setup such as My App Server, you may be able to:
- install a ready-made Tomcat or Java version with one click,
- run a private JVM for a specific site or application,
- switch runtime versions when your app requirements change,
- upload and configure custom app server components manually when needed.
This makes runtime selection a hosting decision as much as a development decision.
Which Java version should you choose for a UK project?
The best Java version for a UK-hosted project depends on the age of your application, the framework stack, and how stable you want the platform to be. In practice, these are the most common choices:
Java 8
Use Java 8 only if your application or library stack requires it. It remains common in legacy systems, older Spring applications, and older Tomcat deployments. Many business applications still depend on Java 8 because of frameworks, build tools, or vendor packages that have not been upgraded.
Choose Java 8 when:
- your application was built for Java 8,
- a dependency only supports Java 8,
- you are migrating an older WAR application and want to avoid code changes.
For a new application, Java 8 is usually not the first choice unless you have a strong compatibility reason.
Java 11
Java 11 is a widely used LTS version and is often a safe middle ground for hosting. It offers better long-term support than older releases and works well with many frameworks and servlet-based applications. If your app is not yet ready for Java 17 or Java 21, Java 11 is often a practical upgrade from Java 8.
Choose Java 11 when:
- your framework supports it and your app has already been tested on it,
- you want a stable LTS runtime for production hosting,
- you are modernising an older application without jumping straight to the newest release.
Java 17
Java 17 is a very common current LTS choice for new and existing applications. It is a strong option for many Tomcat hosting setups because it balances stability, performance, and broad ecosystem support. If your libraries and application framework support Java 17, it is often one of the best choices for a hosted Java project.
Choose Java 17 when:
- you are building a new application and want an LTS runtime,
- your stack supports modern Java without requiring the latest release,
- you want a good balance of long-term stability and compatibility.
Java 21
Java 21 is a newer LTS release and may be the best choice for applications that have been verified against it. It is suitable for new projects and for teams that want to stay closer to current Java development. However, you should confirm framework, library, and application server compatibility before choosing it, especially if you are deploying into a managed hosting environment with a fixed Tomcat setup.
Choose Java 21 when:
- your project has been tested with Java 21,
- your framework and dependencies support it,
- you want to start with a modern LTS runtime for a new deployment.
How to decide based on your application
Instead of asking which Java version is “best” in general, use the following compatibility checks.
1. Check the framework requirement
Frameworks often define the minimum and recommended Java versions. For example, a Spring-based application may require at least a certain Java release, while older application code may only run reliably on Java 8 or Java 11. Always check the framework documentation first.
2. Check your build output
If your application is compiled with a newer Java version, it may not run on an older runtime. This matters if you build locally and deploy to a hosted Tomcat instance. The JDK used for compilation and the runtime used for execution should be aligned with your deployment target.
3. Review third-party libraries
A single dependency can determine your runtime choice. Common examples include older JDBC drivers, XML processing libraries, payment integrations, or internal vendor packages. If one library is not compatible with a newer runtime, your whole deployment may fail.
4. Consider your hosting setup
In a shared hosting account with a private JVM, you want a runtime version that is easy to manage and supported by the platform. A control panel-based setup such as My App Server is useful because it lets you install a Java version, manage the service, and keep the application isolated from other sites in the same account.
5. Prefer LTS for production
For most business sites, LTS versions are the best choice because they provide a more predictable support cycle. If you do not need the newest language features, Java 11, 17, or 21 are usually safer than a non-LTS release.
Java runtime and Tomcat: what should match?
When hosting servlet or JSP applications, the Java runtime and Apache Tomcat version should be compatible. Tomcat itself has specific Java requirements, and some Tomcat releases do not support older Java versions. If you select the wrong combination, the service may not start or your app may behave unpredictably.
As a rule:
- check the Tomcat version supported by your app,
- check the Java version required by that Tomcat release,
- confirm that your application framework supports both.
In a hosting environment where My App Server provides ready-made Tomcat and Java options, this is easier because the service can be installed with a known compatible version. If you upload a custom app server or use a manually configured private JVM, compatibility becomes your responsibility.
Recommended approach for different scenarios
New Java web application
If you are starting from scratch, choose a current LTS release that your framework supports. In most cases this means Java 17 or Java 21. For Tomcat-based hosting, verify that the version of Tomcat you plan to use is also compatible with that runtime.
- Best default: Java 17
- Modern choice: Java 21
- Avoid choosing older versions unless required
Existing application built on Java 8
If the app has been running for years and uses older libraries, start by testing it on Java 11 or Java 17. If it fails, keep Java 8 until you can update the code or dependencies. Do not upgrade the runtime only because a newer version is available in the panel.
Legacy application with older Tomcat
Some older servlet applications depend on specific Tomcat and Java pairings. In that case, the safest move is to preserve the exact combination used in development or the previous hosting environment. If you are migrating to a managed hosting account, document the current runtime, servlet container version, and required JVM arguments before changing anything.
Small business site with a WAR deployment
If you are deploying a WAR file for a line-of-business app, choose an LTS runtime and keep the deployment simple. The goal is predictable service operation, easy updates, and low maintenance. A private JVM and Tomcat instance managed through Plesk is usually a good fit for this use case.
How runtime choice affects hosting operations
Your Java runtime version affects more than whether the app starts. It also influences deployment, troubleshooting, and maintenance.
- Deployment: a WAR built for one Java version may not deploy cleanly on another.
- Logging and errors: runtime mismatches can cause startup errors, class loading problems, or missing method exceptions.
- Security: newer runtimes receive updates and fixes for known issues.
- Supportability: a version aligned with your hosting platform is easier to maintain over time.
If your hosting account includes service control in Plesk, you can usually restart the Java service after changing the runtime or updating the app. That makes controlled testing much easier than on a manually administered server.
Practical checklist before you choose a runtime
Use this checklist before installing or switching Java versions in your hosting panel:
- Identify the framework and application server requirements.
- Confirm the Java version your code was compiled against.
- Check third-party libraries for runtime restrictions.
- Review the supported Tomcat version.
- Decide whether you need Java 8, 11, 17, or 21.
- Test on a staging or development copy before changing production.
- Restart the service and verify application logs after deployment.
How this works in a Plesk-based Java hosting setup
In a hosting platform with My App Server, runtime management is usually designed for practical self-service. You can install a Java/Tomcat version from the control panel, run a separate JVM for your site, and manage the service without needing a full enterprise application server stack. This is especially useful for JSP hosting, servlet hosting, and smaller Java web applications that need isolation and a clean deployment path.
Typical tasks include:
- creating or selecting a Java app server instance,
- choosing an available runtime version from the supported list,
- uploading the WAR or web application files,
- checking service status and logs after startup,
- switching versions if the app needs a different runtime.
If your version is not available as a ready-made install, a custom app server or manual setup may still be possible depending on the account limits and service configuration.
Common mistakes when choosing a Java runtime
Many runtime issues come from choosing based on the newest available version rather than the application’s actual requirements.
- Upgrading without testing: moving from Java 8 to Java 17 or 21 can expose code or dependency issues.
- Ignoring Tomcat compatibility: Java and Tomcat must work together.
- Using a non-LTS version for production: this can create unnecessary upgrade pressure.
- Deploying with a different compile target: code built for a newer Java release will not run on an older runtime.
- Forgetting about startup arguments: some apps need memory settings or JVM options that must be kept consistent.
FAQ
Is Java 17 a good default for hosted web applications?
Yes. For many applications, Java 17 is a strong default because it is an LTS release with broad framework support. It is often a good balance between compatibility and modern runtime features.
Should I always use the newest Java version?
No. The newest version is only the right choice if your application, libraries, and Tomcat version all support it. In hosting, stability and compatibility matter more than using the latest release.
Can I run an older Java app on a newer runtime?
Often yes, but not always. Some older applications depend on APIs, behavior, or libraries that changed over time. Always test before switching the runtime in production.
What if my application only works on Java 8?
Keep Java 8 until you can update the application. In a managed hosting setup, it is better to run a compatible version reliably than to force an upgrade that breaks the app.
Do I need a special runtime for Tomcat hosting?
You need a runtime version that is compatible with the Tomcat release you are using. The exact requirement depends on the Tomcat version and your application stack.
Can I change the Java version later?
Usually yes, especially in a control panel-based hosting environment. However, you should test the app after each change and review the logs to confirm that the service starts correctly.
Conclusion
For Java hosting in the UK, the right runtime version is the one that matches your application and framework requirements while giving you a stable support path. For legacy apps, that may be Java 8 or Java 11. For most new projects, Java 17 is a safe and practical choice, and Java 21 is a strong option if your stack supports it. In a managed hosting environment with Plesk and My App Server, you can usually install and control the runtime more easily, run a private JVM, and keep your Tomcat-based application isolated and manageable.
If you are unsure, start with the version your application was designed for, then plan an upgrade only after testing compatibility with Tomcat, libraries, and your deployment process.