When a Java runtime changes, the effect on your application is usually not limited to the JVM itself. A newer Java version can change class loading behaviour, TLS defaults, garbage collection, module access, bytecode compatibility, and library requirements. On a managed hosting platform, this matters because your app may run inside a control panel–managed service such as Tomcat or a private JVM, and the same deployment can behave differently after an update even if your source code has not changed.
For UK Java hosting customers, the key question is not only can the application start, but also does it still behave correctly after the runtime update. This is especially important if you use a hosting control panel such as Plesk with a Java extension like My App Server, where you may install a ready-made Tomcat/Java version or upload and configure a custom runtime manually.
Why runtime updates can affect Java application compatibility
Java applications depend on a combination of factors: the JDK or JRE version, the application server, the servlet specification, third-party libraries, and sometimes OS-level settings such as file permissions or SSL configuration. A runtime update can change any of these at the JVM level, even when the hosting account, domain, and application files stay the same.
Common compatibility risks include:
- Bytecode version mismatch - an app compiled for a newer Java version will not run on an older runtime.
- Deprecated or removed APIs - code that used older internal Java APIs may fail after an upgrade.
- Stricter module access - newer Java releases enforce access rules more strictly than older versions.
- Library incompatibility - frameworks such as Spring, Hibernate, or older servlet libraries may require a specific Java range.
- TLS and security changes - updates can disable outdated protocols or ciphers, affecting API calls and external integrations.
- Tomcat and servlet container differences - a Tomcat upgrade may change supported servlet/JSP levels or configuration behaviour.
In a hosting environment, the runtime update can also affect startup scripts, environment variables, JVM memory settings, and service management. That is why compatibility testing should be part of every Java version change, whether you are moving from Java 8 to 11, 11 to 17, or applying a smaller patch update.
What changes after a Java runtime update
1. The JVM version may change
The most obvious change is the Java runtime version itself. If your application was built and tested against Java 8, a move to Java 11 or Java 17 may expose hidden assumptions. Some code works unchanged, but older dependencies, reflection-heavy frameworks, and code using internal JDK packages often need review.
This is relevant on shared hosting when you select a different Java runtime in My App Server or switch your Tomcat installation to another installed version. Even if the application is deployed as the same WAR file, the JVM underneath can produce different results.
2. Default behaviour can shift
Java updates often change defaults for garbage collection, TLS handshake behaviour, character encoding handling, and security policies. Your application may still compile, but runtime behaviour can differ. For example, a service that talks to an older payment gateway, CRM, or external API may fail because the remote system expects older TLS settings that the new JVM no longer enables by default.
3. Libraries may need newer versions
A runtime update often forces a dependency refresh. Frameworks and application servers tend to follow Java release cycles. If you update the Java runtime but keep an older framework version, the application may start with warnings or fail at runtime. This is common with older build pipelines where the application was developed for a previous LTS version and no compatibility check was done before deployment.
4. Server-side configuration can need adjustment
Tomcat and other servlet containers may require JVM options, memory arguments, or connector settings to be revisited after a runtime upgrade. A setting that worked under one Java version may behave differently under another. This is especially relevant when the hosting account uses a private JVM and a service controller in Plesk, because the service definition itself can be tied to specific runtime paths and startup parameters.
How this affects Java hosting in Plesk and My App Server
In an ITA-style Java hosting setup with My App Server, you typically have a practical level of control over the runtime environment. You can install a supported Java/Tomcat version with a button or configure a custom app server manually. That flexibility is useful, but it also means compatibility is your responsibility at the application level.
Typical hosting-side changes that can affect compatibility include:
- switching the active Java version for a domain or service
- upgrading Tomcat to match the new Java runtime
- changing JVM memory settings or startup options
- replacing a bundled runtime with a custom one
- adjusting service control settings in the Plesk extension
If your app is a WAR-based servlet or JSP project, the application server version is just as important as the Java version. A runtime update that is technically valid may still break a deployment if the container version is too old or too new for the app’s expected servlet/JSP behaviour.
Compatibility risks by application type
Servlet and JSP applications
Servlet and JSP applications are usually straightforward to host, but they still depend on the servlet container version and the Java runtime. If your app uses older servlet APIs or legacy JSP tag libraries, test carefully after any Java upgrade. Problems often appear as startup errors, view rendering failures, or missing classes at runtime.
Spring-based applications
Spring applications are often tolerant of runtime upgrades, but only within the supported Java range of the specific framework version. Older Spring Boot versions may not support newer Java releases. If the application uses embedded Tomcat or external Tomcat in the hosting account, compatibility needs to be checked both at the framework layer and the container layer.
Legacy applications
Older applications are the most likely to break after a runtime update. They may rely on removed Java EE packages, outdated authentication flows, or reflection into internal Java classes. In hosting terms, these apps may need a pinned Java version instead of automatic upgrading. That is one reason a managed Java hosting setup with manual version control is useful: it lets you keep a known-good runtime while you plan a code or dependency update.
Applications with external integrations
Apps that call APIs, SFTP servers, mail servers, or payment gateways often fail after a runtime change because of security defaults rather than application code. A newer JVM may reject weak certificates, old ciphers, or obsolete protocols. If the application works locally but fails on the hosting platform after an update, check the TLS stack first.
Best practice before changing the runtime
The safest approach is to treat a Java update like a controlled compatibility change, not a routine maintenance task. Before you switch runtime versions in Plesk or My App Server, review the following points.
- Check the supported Java range for your framework, container, and libraries.
- Review release notes for the target Java version and Tomcat version.
- Verify build target compatibility in your CI/CD or local build tool.
- Inventory third-party JARs and confirm they are still maintained.
- Back up the application, configuration, and deployed WAR files.
- Test in a staging or clone environment before changing production.
- Document current JVM flags, including memory, GC, and SSL-related options.
In a managed hosting environment, it is also wise to note whether the app uses a default service instance or a custom one. If you created a custom app server in My App Server, keep a record of its configuration so you can roll back quickly if the updated runtime causes issues.
Step-by-step compatibility checklist after a runtime update
Step 1: Confirm the Java version in use
After the update, verify that the application is actually running on the intended Java version. Do not rely on the version selected in the control panel alone. Check the active runtime from the service status, Tomcat logs, or application diagnostics. In some hosting setups, the selected version and the running version can differ if the service was not restarted.
Step 2: Review startup logs
Look for warnings about unsupported APIs, deprecated JVM options, module access, or missing classes. Startup logs are often the fastest way to identify compatibility problems. A clean startup does not guarantee full compatibility, but it is a strong first signal.
Step 3: Run application smoke tests
Test the most important application paths first:
- login and authentication
- form submission
- database connectivity
- file upload and download
- email sending
- external API calls
- PDF generation or report export
These simple checks often reveal runtime-related issues more quickly than deeper functional testing.
Step 4: Check dependency compatibility
Review the versions of your framework, servlet API, logging libraries, database drivers, and HTTP clients. A Java update may require a later dependency version, especially for older codebases. If the application uses a build file such as Maven or Gradle, update the declared target version and retest locally before redeploying.
Step 5: Validate Tomcat and JVM settings
Confirm that your Tomcat configuration still matches the Java runtime. Memory allocation, garbage collection flags, encoding options, and connector settings should be checked after the change. In My App Server, this is particularly important when using a private JVM, because startup arguments may need adjustment when the runtime changes.
Step 6: Test certificates and outbound connections
If the application connects to external services, verify SSL/TLS handshakes, certificate chains, and outbound authentication. Newer Java releases can reject older or weak configurations that previously worked. This is a common reason why an application appears healthy internally but fails during integrations.
Step 7: Keep a rollback path ready
Always keep a known-good runtime available until you are sure the update is safe. On a hosting platform with multiple Java versions, this usually means preserving the previous runtime configuration so you can switch back quickly if necessary. Avoid deleting the old setup until the new one has been stable for a reasonable testing period.
How to reduce compatibility problems on hosting platforms
You can reduce the risk of runtime-related failures by making version changes in small steps and by aligning the app server version with the Java version. For hosted Tomcat applications, the safest approach is often:
- test the application locally on the target Java version
- deploy it to a staging domain or test instance
- verify Tomcat startup and key business functions
- only then switch the runtime on the live hosting account
This process is practical for UK hosting customers who want controlled deployment without moving to a complex enterprise platform. A service-managed environment such as My App Server gives you enough control to choose Java versions, manage a private JVM, and run a separate Tomcat instance while still keeping the setup manageable from the hosting control panel.
Other useful precautions include:
- prefer supported LTS versions where possible
- avoid mixing very old libraries with very new Java runtimes
- keep Tomcat and the JDK updated in a coordinated way
- store runtime-specific settings in version control
- monitor logs after every change, not just the first deployment
Signs that the runtime update caused a compatibility issue
After a Java upgrade, these symptoms often indicate a compatibility problem:
- Tomcat service starts and then exits immediately
- the application shows a blank page or HTTP 500 errors
- JSP files compile incorrectly or fail to render
- database connections fail because of driver incompatibility
- external API calls fail only on the hosting server
- the app works in development but not in the hosted environment
- new warnings appear in catalina logs or application logs
When this happens, do not focus only on the app code. Check the runtime, container version, JVM options, and library compatibility together. A small change in any one of these layers can trigger a visible failure.
When to keep an older Java version
Sometimes the best compatibility decision is to stay on the older supported runtime until the application is ready. This is reasonable when the app is stable, business-critical, and depends on libraries that have not yet been updated. In a managed hosting account, keeping the older runtime can be safer than forcing an upgrade that introduces downtime.
However, do not treat this as a permanent solution. Older Java versions eventually stop receiving updates, and that can create security and maintenance risks. The better long-term approach is to plan a migration path, update dependencies, and test the app against a newer runtime in a controlled way.
FAQ
Will a newer Java runtime always break my application?
No. Many applications run correctly on newer Java versions, especially when they use maintained frameworks and standard APIs. The risk increases with older code, outdated dependencies, and custom JVM settings.
Is a Tomcat update as important as a Java update?
Yes. For servlet and JSP hosting, Tomcat compatibility is part of the runtime picture. Even if the Java version is supported, a different Tomcat version can change deployment behaviour or supported APIs.
How do I know whether my app supports Java 17 or newer?
Check the framework documentation, library release notes, and your build configuration. If possible, test the application in a staging environment on the target Java version before changing the live hosting account.
Can I use a custom runtime on a shared hosting account?
In setups like My App Server, yes, custom app servers and private JVMs can be configured within the hosting account. The exact approach depends on the available service controls and the limits of the hosting plan.
What should I check first if the app stops after an update?
Start with the logs, the active Java version, Tomcat startup messages, and external connection errors. These are the quickest indicators of runtime compatibility problems.
Should I compile against the newest Java version immediately?
Only if your application and dependencies fully support it. Many teams keep the compile target aligned with the production runtime to reduce surprises during deployment.
Conclusion
Runtime updates can improve security and performance, but they can also change how a Java application behaves on a hosting platform. In UK Java hosting environments, especially when using Plesk and a service such as My App Server, the best practice is to treat every Java or Tomcat change as a compatibility event. Check the framework version, review dependencies, test startup and business functions, and keep a rollback plan ready.
If you manage servlet, JSP, or private JVM hosting for small to medium applications, this approach helps you stay stable while still benefiting from newer runtimes. Careful version control, controlled testing, and clear service management are the key steps to avoiding unexpected downtime after a Java update.