If your Tomcat application expects a different runtime version than the one currently installed, the application may fail to start, behave unpredictably, or work only partially. In a managed Java hosting setup, this usually means there is a mismatch between the Java version your application was compiled for and the Java runtime used by your private JVM or Apache Tomcat service in Plesk.
With a hosting platform that provides Java hosting through a control panel extension such as My App Server, this problem is common when deploying an existing WAR, JSP, or servlet application that was built for an older or newer Java release. The good news is that the issue is usually easy to identify and resolve once you understand whether the problem is caused by the Java version, the Tomcat version, or both.
What runtime version mismatch means
A runtime version mismatch happens when the application expects one Java environment, but the server runs another. In Tomcat hosting, this usually involves two layers:
- Java runtime — the JVM version used to execute the application
- Tomcat version — the servlet container that loads and serves the application
For example, an application might be compiled for Java 11, but the hosting account is running Java 8. Or the application may rely on APIs or libraries that are not available in the current Tomcat release. In both cases, the application can fail before it even reaches the browser.
In shared Java hosting with a private JVM, the runtime version matters even more because the app is isolated from the system-wide Java installation. You may have a separate Apache Tomcat service and a selected Java version inside your own hosting account, which gives you control, but also means version selection must be correct.
Typical symptoms of a Java version mismatch
When the runtime version does not match the application requirements, you may see one or more of the following symptoms:
- Tomcat fails to start after deployment
- The application returns a 500 error
- Classes fail to load during startup
- JSP pages compile incorrectly or do not render
- Logs show
UnsupportedClassVersionError - Logs show missing methods, missing classes, or framework initialization errors
- The app starts, but some features behave incorrectly
Some errors appear immediately in the Tomcat logs, while others only show up when specific code paths are executed. That is why checking logs is the first and most useful step.
Common causes of the problem
The application was built for a newer Java version
This is the most common cause. If a developer builds an application with Java 17 features and deploys it on Java 11, the runtime cannot understand newer bytecode or language features. The application may fail with a version error before startup completes.
The application depends on an older Java version
Some older applications depend on libraries or frameworks that were written for Java 8 or earlier. They may still compile on a newer JVM, but certain behaviors, reflection calls, or deprecated APIs may break. In this case, moving to a newer runtime without testing can introduce compatibility issues.
The Tomcat version is not compatible with the app
Tomcat itself has compatibility requirements. A web application that worked on one Tomcat release may need adjustments on another because of changes in the servlet specification, JSP support, or class loading behavior. This is especially relevant when an application relies on an older framework stack.
The app uses libraries bundled for a different Java level
Sometimes the application WAR includes third-party libraries compiled for a different Java target. The main application may be compatible, but one bundled JAR may not be.
The deployment environment was changed after installation
If you switched the Java version in your hosting control panel, updated Tomcat, or replaced the application package, the app may now expect something different from what is active in your My App Server instance.
How Tomcat hosting handles runtime selection
In a managed hosting environment with Plesk and a Java extension such as My App Server, you can usually choose a runtime version when creating or managing the service. This is useful because it lets you match the application to the right Java release without changing the whole server for everyone.
Depending on the hosting plan and available tools, you may have:
- Ready-to-install Tomcat and Java versions
- The option to select a specific JVM for the service
- Manual upload and configuration for custom app server versions
- Service control from the hosting panel
- Separate management for logs, startup, and deployment path
This model is practical for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM hosting for small and medium applications. It is not intended to replace large enterprise application server platforms, but it gives you enough control to match most typical web application requirements.
How to check which runtime version your application needs
Before changing anything in the hosting panel, identify the version requirements of the application.
Check the application documentation
Start with the official documentation for the framework or product. Look for:
- Supported Java versions
- Supported Tomcat versions
- Required servlet or JSP specification
- Known compatibility limitations
Check the build configuration
If you have access to the source code, inspect the build file:
- Maven: check
maven-compiler-pluginsettings - Gradle: check
sourceCompatibilityandtargetCompatibility - Bytecode target: confirm the
--releaseor target level
If the code targets Java 17, it should not be deployed on a Java 11 runtime. If it targets Java 8, it may usually run on a newer JVM, but still needs testing.
Inspect the application logs
Tomcat logs often reveal the exact mismatch. A message like UnsupportedClassVersionError usually means the runtime is too old for the compiled code. Other messages may point to a missing dependency or an incompatible framework component.
Check the app’s framework version
Frameworks such as Spring, Struts, Hibernate, or older JSP libraries may have their own runtime constraints. Even if the app compiles, the framework may not be supported on the selected Java version.
What to do if the runtime is too old
If the application expects a newer runtime than the one currently installed, you should move the service to a compatible Java version if the hosting environment supports it.
Step 1: Confirm the minimum required version
Verify the exact Java version needed by the app. Do not rely on assumptions. An application that “works on Java 11” may still need Java 11.0.16 or later because of a library fix.
Step 2: Change the Java version in the control panel
In a Plesk-based setup with My App Server, select the Java runtime version that matches the application’s requirement. If your hosting plan offers multiple ready-made versions, pick the closest supported option that satisfies the app.
Step 3: Restart the Tomcat service
After changing the runtime, restart the service so the new JVM is used. In many cases, the old Java process must be fully stopped before the new version takes effect.
Step 4: Redeploy or recheck the application
After the restart, redeploy the WAR if needed and check the logs again. If the application still fails, there may be a second compatibility issue, such as a Tomcat mismatch or a bundled library problem.
What to do if the runtime is too new
If the application was written for an older Java version, a newer runtime may still cause problems. This is more subtle because the app might start but fail later.
Look for deprecated or removed APIs
Older Java applications may depend on APIs that are no longer present or behave differently in newer releases. This can affect authentication modules, XML processing, date handling, or security providers.
Test the application after every version change
If you must upgrade the runtime, test not only startup but also the core features of the application. For example:
- Login flow
- Database access
- File upload and download
- JSP rendering
- Background jobs or scheduled tasks
Consider running the older supported version
For legacy applications, the safest option is often to keep the runtime at the version officially supported by the application. In managed hosting, that is often easier than refactoring the code immediately.
How Tomcat version and Java version work together
Many users focus only on Java, but Tomcat version matters too. A runtime version mismatch may be caused by either component, or both.
- A newer Java runtime may be fine, but the installed Tomcat release may not support the application’s servlet expectations.
- An older Tomcat release may still run on the selected JVM, but the app may require a newer servlet container.
- Some frameworks depend on combinations of Java and Tomcat that are tested together.
When using a private Apache Tomcat service in hosting, always check both compatibility layers. If your platform offers several Tomcat versions, choose the one that matches the app’s official support matrix.
Practical troubleshooting steps in My App Server
If you are using a managed Java hosting environment with My App Server, the following workflow is usually the fastest way to resolve the problem:
- Open the hosting control panel and confirm the selected Java version.
- Check the Tomcat version assigned to the app server instance.
- Review the Tomcat logs for version-related errors.
- Compare the application requirements with the active runtime.
- Switch to a compatible runtime if one is available.
- Restart the service and verify the deployment.
- If needed, upload a custom app server version that matches the app.
This process is especially useful when the application was transferred from another environment and the old runtime assumptions were not documented.
Examples of version mismatch scenarios
Example 1: Java 17 application on Java 11
A newer application is packaged with classes compiled for Java 17. When deployed to Java 11, Tomcat starts but the application fails with a class version error. The fix is to use Java 17 or rebuild the app for Java 11 if the codebase supports it.
Example 2: Legacy app on a newer JVM
An older JSP application runs on Java 8 in development, but the hosting account is switched to Java 21. Startup works, but authentication and reporting features fail because an old library depends on removed behavior. The fix may be to use the original Java version or update the framework and libraries.
Example 3: Tomcat version mismatch
A WAR file was designed for an older servlet container. It deploys, but one of the initialization listeners fails. The Java version is correct, but Tomcat is too new or too old for the application’s expected servlet APIs. In this case, changing the Tomcat version is more important than changing the JVM.
Best practices for choosing a runtime version
To avoid runtime mismatch problems, follow a few simple practices when deploying Java applications to hosting:
- Match the runtime to the application’s documented requirements
- Use the same Java version in staging and production whenever possible
- Avoid upgrading Java and Tomcat at the same time unless necessary
- Test every application after a runtime change
- Keep a note of the version that last worked correctly
- Review logs after every deploy
These habits are particularly useful in shared hosting environments where you manage the app server yourself through Plesk, but you still benefit from a controlled platform and service isolation.
When to use a custom app server version
If the ready-made Java or Tomcat versions do not match your application, a custom app server can be the right solution. This is useful when:
- Your application requires a specific patch level
- You need a Tomcat release that is not one of the default install options
- A framework only works with a particular JVM build
- You are moving an existing app from another hosting environment and want to preserve compatibility
Custom versions are especially helpful for maintaining older applications that still need a stable runtime, without changing the application code immediately.
FAQ
Why does my Tomcat application work locally but fail on hosting?
Local and hosted environments often use different Java and Tomcat versions. Your laptop may run Java 21, while the hosting account uses Java 17 or Java 11. Even small differences can expose version incompatibilities.
Can I run any Java application on any Tomcat version?
No. The application must be compatible with both the Java runtime and the Tomcat release. Some applications require specific servlet APIs or Java language levels.
What does UnsupportedClassVersionError mean?
It usually means the application or one of its libraries was compiled for a newer Java version than the runtime currently installed on the server.
Should I always use the newest Java version available?
Not always. The safest choice is the version supported by your application. Newer is not automatically better if the app depends on older libraries or framework behavior.
Do I need to reinstall Tomcat when changing Java version?
Usually no. In many managed hosting setups you only need to change the JVM selection and restart the service. If the app server version itself is incompatible, then a different Tomcat installation may be necessary.
What if my application needs a runtime version not listed in the panel?
Check whether a custom app server can be uploaded or configured manually. If not, the application may need to be adapted to a supported version or moved to a suitable runtime.
Conclusion
When a Tomcat application expects a different runtime version, the issue is usually caused by a mismatch between the application’s compiled Java level, the selected JVM, or the installed Tomcat version. The fastest way to fix it is to confirm the supported versions, compare them with the active runtime in your hosting panel, and switch to a compatible Java or Tomcat release.
In a hosting environment with My App Server, this is one of the main advantages of using a private JVM and controllable Tomcat service: you can match the runtime to the application instead of forcing the application into the wrong environment. For WAR, JSP, and servlet applications, that often means faster deployment, fewer startup errors, and more predictable behavior.