When a Java runtime is updated, a Tomcat application may continue to work exactly as before, or it may start showing startup errors, library conflicts, class loading problems, or changed behaviour in the browser. In managed hosting environments, these issues often appear after a Java version change, a Tomcat update, or a switch between a built-in app server and a custom one. The safest approach is to check compatibility before deploying the update, then verify the application after the change.
In a hosting setup with My App Server, you can usually control the Java version, Tomcat instance, and deployment process from Plesk. That makes compatibility checks easier because you can test the application with a specific runtime instead of relying on a shared default. This is especially useful for JSP hosting, servlet hosting, and smaller Java applications that run well on a private JVM and a dedicated Tomcat instance inside your hosting account.
What changes when the Java runtime is updated
A runtime update usually means a change in one or more of these layers:
- Java version such as moving from Java 8 to Java 11, Java 17, or a newer release.
- Tomcat version, which may bring different servlet support, stricter parsing, or updated defaults.
- JVM behaviour, including garbage collection, memory management, TLS defaults, and module handling.
- System libraries and container-level settings used by the app server.
Even if your application code has not changed, the runtime beneath it may have. That is why “it worked before” does not always mean “it will still work after the update”.
Why Tomcat compatibility can break after runtime changes
Tomcat applications are often built with older assumptions about the Java platform. A runtime update can expose those assumptions. Common examples include:
Removed or restricted Java APIs
Some applications depend on APIs that were available in older Java releases but are no longer accessible by default in newer versions. This often affects legacy libraries, applets, old XML tooling, or code that uses internal JDK classes.
Stricter class loading and module rules
Newer Java releases may enforce access rules more strictly. A library that previously loaded without issues can fail with ClassNotFoundException, NoClassDefFoundError, or reflective access warnings. This is one of the most common causes of compatibility problems after a runtime update.
Library version conflicts
If your application ships its own JAR files and the new runtime or Tomcat version ships different dependencies, you may see conflicts between old and new classes. The result can be startup failures, missing methods, or strange runtime errors.
TLS and security defaults
Java updates often tighten security defaults. This can affect outgoing HTTPS calls, older certificates, weak cipher suites, or legacy integrations with third-party services. An application may start correctly but fail when connecting to an API, database proxy, or external authentication provider.
Changed servlet or JSP behaviour
Tomcat updates can change how requests, sessions, encodings, welcome files, or JSP compilation are handled. Applications that relied on older behaviour may need a configuration adjustment or code update.
Typical symptoms after a Java or Tomcat update
If your application becomes incompatible after a runtime change, you may notice one or more of the following:
- Tomcat does not start after deployment.
- The application deploys, but shows a 500 error in the browser.
- JSP pages fail to compile.
- Logs contain class loading or reflective access errors.
- Session handling behaves differently after restart.
- Requests to external APIs fail with SSL or certificate errors.
- Character encoding or date handling appears changed.
- A library that worked in the previous runtime stops loading.
If you see these symptoms after an update, the issue is often compatibility-related rather than a hosting fault.
How to check compatibility before changing the runtime
Before updating Java or Tomcat, review the application’s requirements and compare them with the target runtime.
1. Check the supported Java versions
Look at the application documentation, framework notes, and third-party library requirements. Many frameworks specify which Java versions they support. If the application was designed for an older Java release, test carefully before moving to a newer one.
2. Review Tomcat and servlet requirements
Some applications depend on a specific servlet API level or Tomcat behaviour. If you use WAR deployment, make sure the application packaging matches the target Tomcat version.
3. Audit third-party libraries
Check whether any libraries are outdated or unmaintained. A single old JAR can block the entire application after a runtime upgrade. This is especially common in older Java hosting projects that were created years ago and then left unchanged.
4. Inspect configuration files
Review application properties, context descriptors, server.xml-related settings, and environment-specific configuration. Runtime changes can make hardcoded ports, old TLS settings, or memory arguments invalid.
5. Look for deprecated or internal API usage
If the code uses internal JDK packages, custom class loaders, or old reflection techniques, it is more likely to fail after a Java update. Static analysis and test logs can help identify risky areas.
Best practice: test the update in a separate app server instance
For hosted applications, the safest method is to test the new runtime in a separate Tomcat instance or a separate application path before switching production traffic. In a Plesk-based setup with My App Server, this can be done by installing a different Java/Tomcat version for a staging copy of the application.
This approach lets you:
- Keep the current application online while testing.
- Compare logs and behaviour between runtime versions.
- Roll back quickly if the new runtime is not compatible.
- Validate JSP compilation, session handling, and external connections.
If you manage a small or medium Java application, this method is often enough to avoid downtime without introducing complex deployment tooling.
How runtime updates affect Tomcat applications in My App Server
With My App Server, you can run your own Apache Tomcat and a private JVM inside your hosting account. That gives you practical control over compatibility, because you can align the runtime with your application needs instead of forcing the application to adapt immediately.
In this setup, runtime updates may affect:
- the Java version used to run the JVM,
- the Tomcat version used to host the WAR package,
- startup parameters such as memory limits or encoding settings,
- the behaviour of JSP compilation and servlet loading,
- service control from Plesk when starting, stopping, or restarting the app server.
The practical advantage is that you can manage these parts from the control panel and apply changes in a controlled way. If the application depends on a particular Java release, you can keep that version until the code and libraries are ready for an upgrade.
Recommended update workflow for hosting customers
Use the following workflow when you plan to change the runtime behind a Tomcat application.
Step 1: Back up the application
Save the application package, configuration files, uploaded content, and any database backups. Even when the change is minor, compatibility issues can create startup failures or data-handling errors.
Step 2: Record the current runtime details
Note the active Java version, Tomcat version, JVM options, and any custom configuration. This makes rollback easier if the application breaks after the update.
Step 3: Test on a copy of the app
Deploy the application to a staging environment or a separate app server instance. Run the main user flows, login process, file upload, background tasks, and external integrations.
Step 4: Review logs immediately after startup
Check Tomcat logs, application logs, and any console output for warnings and errors. Pay attention to messages about class loading, access restrictions, SSL, deprecated APIs, and JSP compilation.
Step 5: Validate browser behaviour
Open the application in a browser and test the main pages. Confirm that forms submit correctly, sessions remain active, and static assets are served as expected.
Step 6: Confirm outbound connections
If the app connects to databases, payment gateways, APIs, or mail services, verify that those connections still work after the update. Many compatibility problems appear only during outbound TLS connections.
Step 7: Move to production only after verification
Once the application works reliably in the new runtime, switch production to the updated version. If not, keep the older runtime and review the application or library stack first.
Common compatibility issues and how to fix them
Application fails to start after Java upgrade
This often means the app relies on an unsupported API, an old library, or a startup option that no longer works. Check the Tomcat logs, then verify the Java version requirements of the framework and dependencies.
JSP pages no longer compile
JSP compilation problems can occur after Tomcat or Java changes. Check for syntax issues, encoding mismatches, old tag libraries, or libraries that are not compatible with the new servlet/JSP environment.
HTTPS calls fail
If the application uses external HTTPS services, a Java update may reject older certificates or weak TLS settings. Update certificates, use supported cipher suites, and confirm that the external service also supports modern TLS.
Old libraries use restricted internal APIs
Replace outdated dependencies with supported versions. This is often the most reliable fix when moving from Java 8 to newer releases.
Session or encoding behaviour changes
Verify application filters, request encoding, response encoding, and Tomcat connector settings. Small differences in defaults can affect user-visible behaviour.
What to check in Tomcat logs
Logs are the fastest way to identify runtime compatibility problems. When a Tomcat application stops working after an update, inspect:
- catalina logs for startup and shutdown messages.
- application logs for framework-specific exceptions.
- JSP compilation output for page translation errors.
- SSL and handshake errors for outbound connection failures.
- Warnings about illegal reflective access or deprecated APIs.
In many cases, the first error in the log is the most important one. Later messages can be only consequences of the initial failure.
When a runtime update is safe and when it needs code changes
A runtime update is usually safer when the application already uses maintained frameworks and current libraries. You are more likely to get a clean upgrade if:
- the code base is actively maintained,
- the application uses standard servlet and JSP features,
- dependencies are current,
- there is no reliance on internal JDK classes,
- the app has been tested on the target Java version before deployment.
Code changes are usually needed when the application depends on:
- very old frameworks or libraries,
- deprecated XML or security APIs,
- hardcoded JVM assumptions,
- custom startup scripts that were built for an older runtime,
- legacy JSP or servlet patterns that no longer behave the same way.
Practical guidance for Tomcat hosting customers
If you are using a managed hosting platform with Plesk and My App Server, keep these practices in mind:
- Choose the Java version that matches the application’s supported range.
- Use the built-in Tomcat version when it is compatible, or install a custom app server if you need a specific stack.
- Keep a separate test copy before any runtime change.
- Use logs to verify startup and runtime behaviour after every update.
- Avoid large version jumps unless you have confirmed compatibility first.
- Prefer supported libraries and stable servlet/JSP features for long-term maintenance.
This approach is usually sufficient for small and medium Java hosting projects that run as WAR applications, JSP sites, or servlet-based tools.
FAQ
Will my Tomcat application always break after a Java update?
No. Many applications continue working without changes. Problems usually appear when the app depends on older APIs, outdated libraries, or runtime-specific behaviour.
Is a Tomcat update the same as a Java update?
No. Java updates change the JVM and platform behaviour, while Tomcat updates affect the servlet container. Both can impact compatibility, but in different ways.
Can I keep an older Java version if my application needs it?
Yes, if your hosting plan and app server setup support it. In a My App Server environment, one common approach is to keep the version that matches the application until you are ready to upgrade the code and libraries.
What is the first thing to check if the app stops working?
Check the Tomcat logs first. Then verify the Java version, Tomcat version, and recent dependency or configuration changes.
Should I update the application code before updating Java?
If the application is old, that is often the best approach. Update the libraries and remove deprecated usage first, then move to the newer runtime after testing.
Does a private JVM help with compatibility?
Yes. A private JVM gives you more control over the Java version and runtime settings, which makes compatibility testing and rollback easier than using a fixed shared environment.
Conclusion
Runtime updates can improve security and performance, but they can also expose hidden compatibility issues in Tomcat applications. The safest method is to compare requirements, test in a separate environment, review logs carefully, and only then move the change into production. In a hosting setup with Plesk and My App Server, you have practical control over Java, Tomcat, and the app server lifecycle, which makes it easier to manage these changes without unnecessary risk.
If your application depends on a specific Java release or Tomcat behaviour, keep the current runtime until the application and libraries are ready. For hosted JSP, servlet, and WAR-based applications, this controlled approach is usually the most reliable way to handle compatibility after changes.