If a Tomcat application stops working after you change the Java runtime behind Tomcat, the most common reason is version incompatibility between the application, the Tomcat server, and the new JVM. In a managed hosting environment such as Plesk with My App Server, this usually shows up after switching to a newer or older Java release, changing the Tomcat installation, or replacing a custom JVM with a different build.
The good news is that in most cases the application is not “broken” permanently. It is usually failing because of class file version mismatch, removed Java modules, changed JVM options, missing dependencies, or environment differences that only become visible after the runtime change. On a shared hosting account with a private Tomcat instance, these issues can often be resolved by checking the Java version, reviewing the Tomcat logs, and adjusting the app configuration in Plesk.
Why Tomcat applications fail after a Java runtime change
Tomcat runs your web application inside a JVM. When that JVM changes, the runtime environment changes with it. Even if the application files stay the same, the code may no longer match the new Java version or the startup parameters used by Tomcat.
Typical causes include:
- Bytecode compiled for a different Java version — for example, an app compiled for Java 17 will not run on Java 11.
- Removed Java APIs or modules — some older code depends on JDK internals or libraries that are no longer available.
- Changed JVM default settings — memory settings, TLS defaults, garbage collection behavior, or encoding can affect startup and runtime behavior.
- Tomcat version and Java version mismatch — not every Tomcat release supports every Java release.
- Native library or dependency issues — some apps use JNI, image processing libraries, or third-party JARs that are sensitive to Java changes.
- Environment variable differences — the new runtime may not load the same paths, options, or system properties.
In hosted Tomcat environments, the problem often appears right after an update or version switch, which makes it look like Tomcat itself is failing. In practice, the application is usually exposing a compatibility issue that was hidden by the previous Java runtime.
Most common symptoms you will see
After changing the Java runtime behind Tomcat, a broken application may show one or more of these signs:
- Tomcat starts, but the application returns a 500 error.
- The application deploys, but some pages fail to load.
- WAR deployment finishes, but the app crashes on startup.
- Logs show
UnsupportedClassVersionError. - Logs show
ClassNotFoundExceptionorNoClassDefFoundError. - The application hangs during initialization.
- Database, mail, or SSL connections stop working after the Java change.
- Tomcat refuses to start at all after switching the JVM.
If you are using My App Server in Plesk, always check whether the service starts successfully but the application fails inside it, or whether the Tomcat service itself is not able to launch. That distinction helps narrow down the root cause quickly.
Check Java and Tomcat compatibility first
The first thing to verify is whether your Tomcat version supports the new Java runtime. Some Tomcat versions are not compatible with newer Java releases, and older application code may also depend on a specific Java major version.
What to compare
- Java version currently selected for the app server
- Tomcat version installed in My App Server
- Java version used when the application was originally built
- Application framework version such as Spring, Struts, JSF, or legacy servlet libraries
For example, a legacy application compiled and tested on Java 8 may not work correctly on Java 17 without code or dependency updates. Likewise, a newer application may require a modern Java runtime and fail if the server is switched back to an older JDK.
If you are unsure which versions are involved, check the application build files, deployment notes, or the output of the application logs during startup. In a managed hosting account, Plesk or My App Server often exposes the selected runtime version, which makes verification easier.
Look for class file version errors
One of the clearest indicators of a Java mismatch is UnsupportedClassVersionError. This means the application was compiled with a newer Java version than the runtime currently running Tomcat.
Example pattern:
- Application compiled with Java 17
- Tomcat is now running on Java 11
- Startup fails because Java 11 cannot read Java 17 bytecode
The reverse can also happen in different ways: an app compiled for older Java may still start on a newer runtime, but fail because of removed APIs, stricter module access, or dependency changes.
If you see this error, the fix is usually straightforward:
- Switch Tomcat back to the Java version the app expects, or
- Rebuild the application for the new Java version, or
- Update the app dependencies so they match the selected runtime
Check for removed or restricted APIs in newer Java versions
Some applications depend on internal JDK packages or older third-party libraries that worked in earlier Java releases. When the runtime changes, those dependencies may no longer be available or may require extra configuration.
Common examples include:
- Code using internal
sun.*orcom.sun.*classes - XML processing libraries with outdated assumptions
- Older logging frameworks
- Legacy SSL or TLS code
- Applets, old security providers, or deprecated crypto settings
These issues often do not appear until the Java runtime is changed. The app may have worked for years on an older JVM, then fail after a switch to a newer supported runtime in Tomcat hosting.
Review Tomcat logs in Plesk or My App Server
Logs are the fastest way to identify what changed. After a runtime switch, Tomcat startup and application logs often contain the exact reason the app broke.
What to inspect
- Tomcat startup log
- Application stderr/stdout output
- Deploy logs for WAR installation
- Java exception stack traces
- Service control messages in Plesk
Look for:
UnsupportedClassVersionErrorNoSuchMethodErrorClassNotFoundExceptionNoClassDefFoundErrorIllegalAccessErrorInaccessibleObjectException- SSL handshake failures
- Memory-related startup failures
These messages usually point directly to a dependency or runtime issue. If the logs are not enough, compare them with the logs from the previous Java runtime, if you still have access to them.
Check JVM options after the change
When Java runtime changes, old JVM options may no longer be valid. This is common when moving between major Java releases. Options that were accepted by one JVM can be rejected by another, causing Tomcat to stop or behave unexpectedly.
Examples of problematic settings
- Memory flags that are no longer accepted
- Deprecated garbage collection parameters
- Old TLS or cipher configuration
- Custom system properties that are no longer needed or are misspelled
- Extra
--add-opensor module flags missing on newer Java versions
In My App Server, the Java runtime and Tomcat service are managed separately from the application code. That means you should review the service configuration after changing the runtime and make sure the startup options still make sense for the selected Java version.
Step-by-step troubleshooting checklist
Use the following order when an application breaks after a Java runtime change behind Tomcat:
- Confirm the new Java version selected in the app server or control panel.
- Check the Tomcat version and confirm it supports that Java release.
- Read the logs for class version errors, access errors, or missing classes.
- Verify the application’s build target and framework compatibility.
- Review JVM arguments for obsolete or incompatible flags.
- Restart Tomcat cleanly after any configuration change.
- Clear temporary application files if the app caches compiled JSP or runtime data.
- Test with the previous Java runtime if possible to confirm the issue is version-related.
This approach helps separate a deployment problem from a runtime compatibility issue. In many cases, simply returning to the previous supported Java version restores the application immediately.
What to do in Plesk with My App Server
If your hosting account uses My App Server, the platform is designed for managing a private Tomcat instance and Java runtime through Plesk. This makes version changes easier, but it also means the selected runtime must stay aligned with the application requirements.
Recommended actions
- Check which Java version is currently assigned to the app server instance.
- Compare it with the version the application was tested on.
- Use the service control tools to restart Tomcat after changes.
- Review the application deployment path and ensure the WAR or exploded app is still intact.
- Confirm that custom app server settings have not been overwritten during the change.
If the application was installed using one of the ready-made Java/Tomcat versions, switching the Java runtime without checking the application’s compatibility can break startup or request handling. If you uploaded a custom app server setup, double-check all manual configuration files, because they may rely on a specific JDK or Tomcat layout.
How to safely switch Java behind Tomcat
Before changing the Java runtime in a Tomcat hosting setup, it is best to treat the change as a controlled compatibility update.
Safe change procedure
- Back up the application files and configuration.
- Record the current Java version, Tomcat version, and JVM arguments.
- Check vendor documentation for framework compatibility.
- Test the new Java version in a staging copy if available.
- Deploy the change during a maintenance window.
- Restart Tomcat and inspect logs immediately.
- Verify login, database access, file uploads, and SSL endpoints.
For small and medium Java hosting projects, this process is usually enough to prevent downtime. It also makes rollback faster if the new runtime is not compatible with the app.
When the problem is the application, not Tomcat
Sometimes the runtime change only reveals a weak point in the application itself. The app may have been relying on old behavior, outdated dependencies, or untested startup assumptions.
In that case, the solution may be one of the following:
- Recompile the application with the intended Java version
- Update framework and library dependencies
- Replace deprecated code paths
- Adjust configuration files for the new Java runtime
- Add required module access flags when moving to newer Java versions
For JSP hosting and servlet hosting scenarios, also check whether compiled JSP classes or application caches need to be cleared after the runtime switch. Old generated files can cause confusing errors even when the code itself is correct.
How to distinguish a runtime issue from a deployment issue
A runtime issue usually appears immediately after the Java change and affects startup or request processing across the app. A deployment issue, on the other hand, may be caused by an incomplete WAR upload, wrong file permissions, or a broken context path.
Use this quick distinction:
- If Tomcat service fails to start, check JVM options, Java compatibility, and startup logs.
- If Tomcat starts but the app does not, check application logs, dependency errors, and class version mismatch.
- If only one page fails, inspect the code path or template that depends on an unavailable library or feature.
This helps avoid unnecessary changes to the deployment when the actual problem is Java compatibility.
Best practices to prevent the issue in future
To reduce the risk of broken Tomcat applications after a Java runtime change, follow these practices:
- Keep a note of which Java version each application is built and tested against.
- Avoid using internal JDK APIs in application code.
- Use supported framework and library versions.
- Test Java upgrades before applying them to live services.
- Keep JVM options documented for each Tomcat instance.
- Use the same Java version for build and runtime when possible.
- Review Tomcat release notes before changing the JDK.
For hosted environments, this is especially important because a small change in the Java runtime can affect multiple layers at once: the app code, the servlet container, TLS configuration, and startup parameters.
FAQ
Why did my Tomcat app stop working right after a Java update?
Most likely the application is not compatible with the new runtime, or one of its dependencies depends on a Java feature that changed. Check for class version errors and unsupported JVM options in the logs.
Can I keep the same Tomcat and only change Java?
Sometimes yes, but only if the Tomcat version supports the new Java release and the application code is compatible. In many cases, both Tomcat and the app dependencies should be checked together.
What does UnsupportedClassVersionError mean?
It means the application was compiled for a newer Java version than the one currently running Tomcat. You need to use a newer JVM or rebuild the application for the selected version.
Why does the app start on one Java version but not another?
Different Java versions may remove deprecated APIs, enforce module boundaries, or change security defaults. Code that worked on an older runtime can fail on a newer one.
Should I change JVM options when changing Java?
Yes, always review them. Some options are version-specific, deprecated, or no longer valid. A startup failure after a Java switch is often caused by an old JVM argument.
What should I check first in My App Server?
Start with the selected Java version, Tomcat version, and the service logs. Then verify whether the application was compiled for the same runtime.
Conclusion
A Tomcat application usually breaks after changing the Java runtime because something in the application stack was built for the old JVM. The most common causes are class version mismatch, incompatible JVM options, missing APIs, or framework dependencies that no longer match the selected runtime. In a Plesk-based hosting environment with My App Server, the fastest fix is to compare the Java version, Tomcat version, and log output, then either restore the previous supported runtime or update the application for the new one.
If you manage Java hosting, Tomcat hosting, JSP hosting, or servlet hosting on a private JVM, the safest approach is to treat Java changes as compatibility changes, not just service changes. That way you can update with less downtime and avoid surprises after deployment.