Upgrading the Java runtime for a website is usually the right move when your application, framework, or security policy needs a newer JDK or JRE version. In a hosting environment, the decision is not only about features. It is also about compatibility with Tomcat, your control panel setup, deployed WAR files, and whether your app still runs correctly after the change.
For Java websites hosted through a managed platform such as Plesk with My App Server, the safest approach is to upgrade the runtime when there is a clear technical reason, then test the application before switching production traffic. This is especially important for JSP, servlet, and Tomcat-based sites that depend on specific Java versions.
When a Java runtime upgrade is needed
You should consider upgrading the runtime when one or more of the following apply:
- Your application requires a newer Java version than the one currently installed.
- Your framework no longer supports the current version, for example newer Spring, Jakarta EE, or build tool releases.
- You need security fixes available only in a later Java release.
- Your developer tools or libraries have dropped support for older runtimes.
- You are deploying a new version of the site and want to align the runtime with current project requirements.
- Your hosting provider offers a newer Tomcat or JVM build that better matches the application stack.
In practice, most Java runtime upgrades happen for one of three reasons: security, compatibility, or application modernization. If none of these applies, there may be no immediate need to change the runtime.
Signs that your current Java version is too old
There are several practical indicators that the website is running on an outdated Java runtime:
- Deployment fails with messages about unsupported class file versions.
- The application starts on one environment but not on the hosting server.
- Tomcat logs show missing methods, deprecated APIs, or compatibility errors.
- Third-party libraries require a later Java version.
- Your build pipeline produces artifacts for a newer target version than the server supports.
- Security scanning tools warn about an unsupported Java release.
If your site is still working but the runtime is end-of-life, that is also a reason to plan an upgrade. End-of-life versions no longer receive regular public security updates, which can create risk for hosted applications handling logins, forms, or personal data.
How runtime choice affects Java hosting on Plesk
With Java hosting in a Plesk-based environment, the runtime is tied to how your application server is configured. In a setup such as My App Server, you can manage a private JVM and Apache Tomcat instance inside your hosting account. That gives you more control than a generic shared hosting environment, but the runtime still needs to match the application.
Key points to check before upgrading:
- Java version used by the app server.
- Tomcat version and whether it supports the target Java release.
- Deployment format such as WAR, JSP, or servlet application.
- Startup scripts and environment variables used by the service.
- Any custom configuration in web.xml, server.xml, or application properties.
In managed hosting, the runtime is usually upgraded together with the app server service or selected from available versions in the control panel. If a required version is not available as a one-click install, it may still be possible to upload or configure a custom app server and runtime manually, depending on your plan and limits.
Compatibility: what to check before upgrading
Before changing the runtime, confirm compatibility at three levels: application, framework, and server.
Application compatibility
Check whether your source code or compiled classes were built for a specific target version. A common issue is deploying a WAR file compiled for a newer Java version onto an older runtime. This usually leads to startup errors.
Framework compatibility
Frameworks such as Spring, Hibernate, Struts, and various JSP tag libraries often have minimum Java requirements. Review the official release notes for your application stack before upgrading or downgrading the runtime.
Tomcat compatibility
Java and Tomcat versions must be compatible. A newer Java runtime may require a newer servlet container version, while an older Tomcat release may not work well with recent Java builds. When using Apache Tomcat in hosting, always verify that the chosen combination is supported.
Common reasons to upgrade in a UK hosting environment
For websites serving UK users, runtime upgrades are usually driven by the same technical needs as anywhere else, but compliance and operational stability often matter more. Typical reasons include:
- meeting internal security standards;
- keeping a customer portal or business application supported;
- avoiding downtime caused by unsupported components;
- aligning staging and production environments;
- preparing for application redevelopment or migration.
If your website is business-critical, plan the upgrade carefully rather than waiting until the runtime becomes unsupported. A controlled change is much easier than an emergency upgrade after a failure or security notice.
When you should not upgrade immediately
There are also cases where you should avoid upgrading right away:
- Your application vendor explicitly supports only the current runtime.
- You have no test environment and cannot validate the site first.
- The site uses older libraries that depend on legacy Java behaviour.
- You are close to a planned application rewrite.
- The current runtime is stable, supported, and still meets your needs.
Upgrading too early can be risky if the application is old or partially maintained. In that case, the safer option may be to keep the current runtime temporarily and schedule a compatibility review before changing anything.
Recommended process for upgrading a Java runtime
If your hosting account supports Java version selection or a private JVM, follow this process:
1. Identify the current runtime
Confirm the active Java version on the hosting account and note the Tomcat version used by the app server. Also check whether the application uses any custom startup parameters or external libraries.
2. Review application requirements
Check the documentation for your application, framework, or build tool. Look for:
- minimum and maximum supported Java versions;
- required Tomcat or servlet container versions;
- known breaking changes;
- migration notes for newer Java releases.
3. Test in staging first
Before upgrading production, use a staging copy of the site if possible. Deploy the same WAR file, same configuration, and same libraries to reproduce the production environment as closely as possible.
Test at least:
- site startup and shutdown;
- login and form submission;
- database connections;
- file upload and download features;
- scheduled tasks or background jobs;
- error logs during startup and runtime.
4. Check control panel service status
In a Plesk-based hosting environment, verify that the Java service or Tomcat instance is running correctly after the change. If your platform uses My App Server, use the service controls provided in the panel to restart, stop, or verify the app server state.
5. Deploy the updated runtime
If the test is successful, upgrade the runtime in production during a maintenance window. Make sure the deployment package, environment settings, and app server configuration are unchanged except for the intended Java version change.
6. Monitor logs after the switch
Watch the Tomcat logs and application logs closely after the upgrade. Look for warnings, class loading errors, missing dependencies, or performance changes.
What to do if you use a custom app server
Some Java hosting accounts use a standard install, while others need a custom application server configuration. If you are using a custom Tomcat setup or a manually uploaded runtime, the upgrade should be treated like a controlled server change.
In that case, make sure you document:
- the exact Java build in use;
- the Tomcat distribution and version;
- all startup options and memory settings;
- any custom connectors or port settings;
- where application files are deployed;
- how the service is started and restarted.
This makes rollback faster if the application does not behave as expected after the upgrade.
Practical upgrade scenarios
Scenario 1: A legacy JSP site stops compiling
If a JSP application suddenly fails after a library update, the issue may be that the current runtime is too old for the compiled classes or new API usage. In this case, upgrading the runtime may be required, but only after checking that Tomcat also supports the new Java version.
Scenario 2: A framework upgrade requires a newer JVM
When you upgrade a web framework or dependency platform, the vendor may require Java 17 or later. If your hosting account still runs an older version, the safest action is to move to the supported runtime before deploying the new release.
Scenario 3: Security policy requires supported Java
Some teams maintain a policy that no unsupported runtime can remain in production. If your current Java version is approaching end-of-life, schedule an upgrade even if the application still works. This reduces future pressure and avoids last-minute migration work.
Scenario 4: A private Tomcat instance is stable but outdated
If the application is stable and lightly maintained, you may not need an immediate change. However, if the server is using an old Java release, you should still plan a migration path before the version becomes unsupported or incompatible with future updates.
How to reduce risk during the upgrade
Runtime changes are safer when they are done methodically. Best practices include:
- keep a full backup of application files and configuration;
- save the previous runtime version so rollback is possible;
- compare test and production settings;
- avoid changing Tomcat, Java, and application code all at once;
- monitor logs immediately after restarting the service;
- have a rollback plan before the maintenance window starts.
In hosted Java environments, the ability to control the app server from the panel is useful because it makes restart and service verification faster. That is particularly helpful when the runtime upgrade is being done on a small or medium-sized application that does not need a complex infrastructure change.
FAQ
How do I know which Java version my website is using?
You can usually check this in the control panel, in the app server configuration, or by reviewing the startup logs. If you use My App Server, the selected runtime is typically visible in the hosting interface or in the service configuration details.
Should I always use the newest Java version?
No. The newest version is not always the best choice for an existing website. Use the newest version only if your application, framework, and Tomcat release support it. Stability and compatibility matter more than having the latest release.
Can I upgrade Java without changing Tomcat?
Sometimes yes, but not always. The compatibility depends on the specific Tomcat version and the Java release you want to use. Always verify the supported matrix before making the change.
What if my Java app breaks after the upgrade?
Rollback to the previous runtime if possible, then review the logs and compatibility notes. The most common causes are unsupported libraries, class file version mismatches, or Tomcat/Java incompatibility.
Is a runtime upgrade the same as an application upgrade?
No. A runtime upgrade changes the Java environment the site runs on. An application upgrade changes your code, libraries, or deployed package. Both can affect each other, but they are different tasks.
Do I need a private JVM for every Java website?
Not necessarily. A private JVM is useful when you need control over version, service settings, or deployment isolation. For a small or medium Java site, it can be a practical fit, especially when hosted through a managed control panel.
Conclusion
You should upgrade the runtime for a Java website when the application requires it, when the current version is no longer secure or supported, or when a framework or Tomcat update depends on a newer Java release. The key is to check compatibility first, test the change in a staging environment, and only then apply it to production.
In a managed hosting setup with Plesk and My App Server, runtime upgrades are easier to control because you can manage the Java version, Tomcat service, and deployment from one place. That makes it well suited to JSP, servlet, WAR, and smaller Java applications that need a private JVM without the complexity of a larger enterprise platform.