If your Tomcat application expects a different runtime version than the one currently selected in My App Server, the application may fail to start, behave unpredictably, or show errors during deployment. In a managed hosting environment, this usually means there is a mismatch between the Java version your application was built for and the JVM version assigned to the Tomcat instance in Plesk.
The good news is that this is usually straightforward to diagnose and fix. In ITA’s Java hosting setup, you can choose a ready-made Tomcat/Java version or configure a custom runtime for your private JVM. That makes it easier to match the runtime to the needs of your application without changing your codebase more than necessary.
Why runtime version matching matters for Tomcat hosting
Tomcat itself runs on Java, so the runtime version is not just a technical detail. It affects how classes are loaded, which language features are available, what libraries can run, and whether the application can even initialize.
If an application expects Java 8 but the server is using Java 11 or Java 17, several things can happen:
- The application starts normally if it is compatible.
- The deployment fails because of unsupported bytecode or missing dependencies.
- Some features work while others throw runtime exceptions.
- Older libraries break because they rely on removed APIs.
In hosting terms, this is a compatibility issue between the application package and the selected runtime environment. When you use a Tomcat hosting service with a control panel such as Plesk, the runtime version is one of the first settings you should verify after deployment.
What usually happens when the version is wrong
A mismatch can show up in different ways depending on how the application was built and which Java features it uses.
Startup errors
The most common result is that Tomcat starts, but your web application does not. You may see errors such as:
- Unsupported class file major version
- NoSuchMethodError
- NoClassDefFoundError
- ClassNotFoundException
- Deployment time failures in the application log
These errors usually mean the application was compiled with a newer Java version than the runtime provides, or it depends on libraries not available in the selected environment.
Application loads but behaves incorrectly
Sometimes the app starts, but specific features fail. This can happen when the runtime version is technically close enough to boot the application, but not fully compatible with its dependencies.
Examples include:
- Login pages failing due to session or encryption-related issues
- Database drivers not loading correctly
- File upload or image-processing functions behaving differently
- Framework components failing at request time
Performance and memory changes
Different Java runtimes can also affect performance. A newer runtime may improve garbage collection and startup times, while an older runtime may be more stable for a legacy application. If your application is sensitive to memory usage, changing the runtime without testing may produce unexpected results.
Common causes of Java and Tomcat runtime mismatches
Most mismatches happen for one of these reasons:
- The application was built on a newer JDK than the server runtime.
- A framework or library requires a specific Java version.
- The application vendor recommends one version, but another was selected during deployment.
- A custom WAR upload was created for a different target platform.
- The Tomcat instance was upgraded, but the application was not re-tested.
In a shared hosting account with a private JVM, it is especially important to keep track of the version used at build time and the version selected in the control panel. A small version gap can be enough to break a web application.
How to check which runtime your application needs
Before changing anything, confirm the target Java version for your application. This is the fastest way to avoid repeated deployment failures.
Check the application documentation
Start with the official documentation for the framework, CMS, or custom application. Look for statements such as:
- Minimum Java version
- Supported Java versions
- Compatible Tomcat versions
- Required servlet API level
Inspect build files and deployment descriptors
If you manage the application source code, review build files such as Maven or Gradle settings. They often specify the source and target compatibility. A WAR file compiled for Java 17 will not run correctly on an older Java 8 runtime.
Review logs after deployment
If the application has already been uploaded, check the Tomcat logs in Plesk or in the application-specific log output. Error messages usually point directly to the version problem.
Look especially for:
- Class file version errors
- Missing methods in third-party libraries
- Module access errors
- Warnings about deprecated or removed APIs
What to do in My App Server if the runtime is wrong
With ITA’s My App Server in Plesk, you can manage your Java/Tomcat environment more flexibly than with a standard shared hosting setup. That is useful when an app needs a specific runtime version.
1. Compare the selected runtime with the application requirement
Open the My App Server settings and verify the Java version assigned to the current Tomcat instance. Compare it with the runtime requested by the application or framework.
2. Switch to a supported ready-made version if available
If the required version is available as a ready-made install option, choose it and redeploy the application. This is usually the cleanest solution when the application expects a standard runtime.
3. Use a custom app server if you need a different version
If your application needs a version that is not offered as a one-click option, you may be able to upload and configure a custom application server or runtime. This is useful for applications with specific Java compatibility requirements.
4. Redeploy and retest the application
After changing the runtime, redeploy the WAR or restart the service if needed. Then test the main application flows:
- Homepage or landing page
- Login and authentication
- Forms and file uploads
- Database connectivity
- Background jobs or scheduled tasks
5. Check logs again after the change
If the application still fails, the issue may not be only the Java version. It can also be caused by library incompatibility, web.xml configuration, or missing environment variables. Logs are the fastest way to confirm the next step.
Best practices for choosing a Tomcat runtime version
For hosting and control panel environments, the safest approach is to match the application as closely as possible to the runtime it was designed for.
Prefer the version recommended by the application
If the software vendor states that the application supports Java 11, use Java 11 unless you have a specific reason to change it. This reduces the risk of deployment issues.
Do not jump to the newest version without testing
New Java versions can introduce behavioral changes, stricter module rules, or dependency conflicts. A newer runtime is not automatically better for every application.
Keep build and runtime versions aligned
When possible, compile the application for the same Java version that will run it in production. This is especially important for custom JSP, servlet, and WAR-based applications.
Document the version used for each environment
Keep a simple note of the Java version, Tomcat version, and any custom settings used in development, staging, and production. This makes troubleshooting much faster later.
Test updates before changing production settings
If your hosting account allows it, test the new runtime on a staging copy first. This is one of the most practical ways to avoid downtime caused by a version mismatch.
How version mismatch affects common Java web applications
The impact depends on what your application uses under the hood.
WAR-based Java applications
WAR files often depend on a specific servlet API and Java runtime. If the version is too old, deployment can fail. If it is too new, deprecated APIs or libraries may break.
JSP hosting
JSP pages are compiled at runtime. A wrong Java version can cause compilation errors or unexpected behavior when the page is first requested.
Servlet applications
Servlet-based applications are usually sensitive to the Tomcat version as well as the JVM version. A mismatch may appear as request handling errors or session issues.
Framework-based applications
Frameworks such as Spring-based applications often have a clear version matrix. If the Java runtime is outside the supported range, the app may fail during startup or bean initialization.
Signs that you should change the runtime instead of the application
Sometimes the faster fix is to adjust the Tomcat runtime rather than modify application code. That is usually the right choice when:
- The application is legacy and cannot be rebuilt immediately.
- You are deploying third-party software that specifies a fixed Java version.
- The same application works elsewhere with a different runtime version.
- The codebase is stable, and only the environment needs to be aligned.
If you control the source code and build process, updating the application to support a newer runtime can be a good long-term step. But in managed hosting, selecting the correct runtime is often the fastest and least risky solution.
Troubleshooting checklist
Use this checklist if your Tomcat application does not start after a version change or behaves differently than expected:
- Confirm the Java version required by the application.
- Verify the Tomcat version and runtime selected in My App Server.
- Check whether the application was compiled for a newer Java release.
- Review the Tomcat and application logs.
- Look for missing libraries or unsupported APIs.
- Switch to the correct runtime version if needed.
- Redeploy the WAR and restart the service.
- Test login, database access, and the main workflows.
If the application still fails after confirming the runtime, the issue is likely related to configuration, dependencies, or application-specific code rather than Tomcat alone.
FAQ
What does “runtime version” mean in Tomcat hosting?
It usually refers to the Java version used by the JVM running Tomcat. Tomcat depends on Java, so the runtime version determines what the application can execute.
Can an application run on a newer Java version than it was built for?
Sometimes yes, but not always. Many applications work on newer versions, but older libraries or code paths can still fail. Always test before changing the runtime in production.
What error usually means the Java version is wrong?
Unsupported class file major version is one of the clearest signs. It usually means the application was compiled with a newer Java version than the server supports.
Should I always use the newest Java version available?
No. The best version is the one supported by your application. Newer is not always safer for compatibility, especially with legacy WAR or JSP applications.
Can I manage a separate JVM for one application only?
Yes, that is one of the practical benefits of My App Server. A private JVM lets you choose a runtime that fits a specific application without affecting other services in the same hosting account.
What if my application needs a version that is not in the one-click list?
In that case, a custom app server setup may be required. You can upload and configure a custom runtime if your hosting plan and environment support it.
Conclusion
If your Tomcat application expects a different runtime version, the result is usually a startup failure, a deployment error, or unstable behavior after launch. The fix is to match the Java runtime to the application’s requirements as closely as possible.
In ITA’s My App Server environment, this is easier because you can choose from ready-made Java/Tomcat versions or configure a custom application server when needed. That gives you practical control over Java hosting, Tomcat hosting, JSP hosting, and servlet hosting in a managed Plesk environment.
When in doubt, check the application documentation, review the logs, and compare the build-time Java version with the runtime selected in the control panel. In most cases, aligning those versions is enough to get the application running correctly again.