If your JSP application expects a different runtime version than the one currently selected in your hosting account, the application may fail to start, return errors, or behave differently from what you see in development. In a managed hosting environment with Plesk and My App Server, this usually means the JSP container, Java runtime, or Apache Tomcat version does not match the requirements of the application package you deployed.
In practice, the result depends on how far the versions differ. A small mismatch may produce warnings or partial feature issues. A larger mismatch can cause startup failure, class loading problems, missing methods, or errors when the application compiles JSP pages on the fly. The safest approach is to align the runtime version with the application’s documented requirements before deployment.
What a runtime version mismatch means
A JSP application typically depends on several layers of runtime compatibility:
- Java version – the JVM version used to run the application.
- Tomcat version – the servlet container that processes JSP and servlet requests.
- Jakarta/Java EE API level – the API set your application was compiled against.
- Build-time libraries – third-party JAR files that may expect a specific Java level.
If your application expects Java 8 but the hosting account is set to Java 17, or if it was built for an older Tomcat generation but the deployed container is newer, the application may still run, but not always. Compatibility is not automatic. Some applications are forward-compatible, while others rely on removed APIs, deprecated behaviour, or older JSP compilation rules.
On hosted JSP services, this matters because the runtime is part of the service configuration, not just your application folder. In My App Server, the selected Java/Tomcat combination determines how your WAR, JSP, and servlet code is executed inside the private JVM assigned to your account.
Common symptoms of a runtime version mismatch
When the runtime version does not match the application’s expectation, you may see one or more of the following:
- Application fails to start after deployment.
- HTTP 500 errors when opening JSP pages.
- Compilation errors during JSP processing.
- ClassNotFoundException or NoClassDefFoundError messages.
- NoSuchMethodError or UnsupportedClassVersionError.
- Missing or broken functionality in specific pages or servlets.
- Warnings in Tomcat logs about deprecated or removed APIs.
- Application works locally but not on the hosting platform.
These issues are often visible in the service logs from Plesk or in the application output generated by Tomcat. If your hosting account provides service control and log access, reviewing those logs is usually the fastest way to confirm a version mismatch.
What happens on the application side
If the Java version is too old
If your application was compiled with a newer JDK than the runtime supports, the JVM may refuse to start the app. A typical sign is that the class file version is too new for the installed Java runtime. This often happens when a developer builds on Java 11 or Java 17 and uploads the application to an account still using Java 8.
In this case, the fix is usually to select a newer Java runtime in My App Server or rebuild the application for the older target version if the app must remain on that runtime.
If the Java version is too new
Older JSP applications may rely on libraries or APIs removed from later Java releases. The application might deploy successfully but fail at runtime when code reaches a deprecated class or an unsupported security provider. This is common with legacy applications that were written for Java 6, Java 7, or early Java 8 environments.
Even when the code starts, subtle behaviour changes can appear in date handling, TLS configuration, XML parsing, file permissions, or JSP compilation.
If the Tomcat version is different
Tomcat version differences can affect JSP parsing, servlet behaviour, session handling, and how the container loads web.xml settings. A newer Tomcat version may be stricter about configuration, while an older one may not support newer annotations or API expectations.
For example, an application built for a newer servlet specification may rely on features not available in an older container. On the other hand, an application using removed legacy configuration may break after a container upgrade.
If the application expects specific libraries
Some JSP applications are sensitive not only to Java and Tomcat versions, but also to bundled libraries. A mismatch between the application’s expected runtime and the libraries available in the hosting environment can cause hard-to-trace failures. The application may start, but certain pages, forms, or background tasks may fail when they call methods introduced in a newer library version.
How this is handled in My App Server hosting
With My App Server, the runtime is managed per hosting account through Plesk. That means you can choose a ready-made Java/Tomcat version where available, or set up a custom app server if your application needs a specific runtime combination. This is useful for JSP hosting, servlet hosting, and small to medium Java applications that need a private JVM without maintaining a separate dedicated server.
In a typical setup, the hosting workflow is:
- Select or install the runtime version required by the application.
- Deploy the WAR or application files.
- Start the service through the control panel.
- Check logs for startup or compilation errors.
- Adjust the Java or Tomcat version if needed.
This gives you practical control over version compatibility while keeping the service inside your managed hosting account.
How to check which runtime your JSP application needs
Before changing anything in the control panel, confirm the version your application expects. The most reliable sources are:
- Project documentation or installation guide.
- build.gradle, pom.xml, or deployment notes if the app comes from a development team.
- WAR file metadata and application release notes.
- Framework documentation for the version of Spring, Struts, JSF, or another framework used by the app.
- Local development environment where the application was tested successfully.
Look for explicit statements such as “requires Java 8,” “tested with Tomcat 9,” or “supports Servlet 4.0.” If the application vendor lists only a broad range, use the most specific supported version and avoid guessing.
How to match the runtime version in Plesk
If your hosting account uses My App Server, you can usually correct the mismatch by changing the runtime assignment in the service configuration. The exact menu names may vary, but the process is typically straightforward.
Step 1: Identify the current runtime
Open your Plesk account and check the Java service or app server settings. Confirm the currently active Java version and Tomcat version for the application.
Step 2: Compare it with the application requirement
Match the active runtime against the version required by your JSP application. Pay attention to both Java and Tomcat, not just Java alone.
Step 3: Choose the closest supported version
If a direct match is available, select it. If not, pick the version that the application vendor officially supports. For legacy applications, that may mean using an older Java runtime and a compatible Tomcat build.
Step 4: Restart the service
After changing the version, restart the Java service so the new runtime is loaded. In managed hosting, this is essential because the old JVM may still be holding the previous configuration in memory.
Step 5: Retest the application
Open the site, test the main JSP pages, and review the logs. If the app starts but certain pages fail, the issue may be a library mismatch rather than the runtime version itself.
When to rebuild the application instead of changing the runtime
Sometimes the best fix is not to downgrade or upgrade the hosting runtime, but to rebuild the application for the supported environment. This is often the right choice when:
- The app is under active development.
- You control the source code.
- The application uses build tools such as Maven or Gradle.
- You want to move to a newer Java version safely.
- The app depends on libraries that are no longer supported in the old runtime.
Rebuilding gives you a cleaner result because the compiled classes, JSP compatibility, and dependency versions are aligned from the start. In hosting terms, this reduces the risk of repeated runtime errors after deployment.
When to use a custom app server
If your application needs a specific combination that is not available as a standard one-click install, a custom app server may be the better option. This is useful when:
- The app requires an uncommon Java version.
- You need a particular Tomcat build for compatibility.
- The application was migrated from another environment and should keep the same runtime.
- You want full control over the private JVM used by the site.
For hosted JSP and Tomcat workloads, this approach provides flexibility without moving to a more complex enterprise platform. It is especially practical for small and medium deployments that need version control, but not heavy cluster management.
Typical compatibility scenarios
Scenario 1: Legacy JSP site built for Java 8
A legacy application runs on Java 8 and uses old JSP tags and libraries. If the hosting account is switched to a much newer runtime, startup may still succeed, but one or more dependencies can fail. In this case, keeping Java 8 and a compatible Tomcat version is usually safer unless the application has been tested and rebuilt for a newer release.
Scenario 2: New WAR file compiled for Java 17
A newly deployed WAR file compiled with Java 17 will not run on Java 8. The error appears immediately when the JVM tries to load the class files. The solution is to select a Java 17 runtime in the control panel or rebuild the application for a lower target if you need backward compatibility.
Scenario 3: JSP pages fail after a container upgrade
An application may work on one Tomcat version and fail after an upgrade because of stricter servlet parsing or changes in the JSP engine. If the application is not ready for the newer container, you may need to revert to a supported version or update the code and dependencies.
How to troubleshoot version-related JSP errors
If your JSP application does not work after deployment, follow this checklist:
- Confirm the Java version configured for the app server.
- Confirm the Tomcat version and servlet specification level.
- Check application logs for version-specific errors.
- Look for UnsupportedClassVersionError, ClassNotFoundException, or NoSuchMethodError.
- Verify that the application was built with the same target runtime.
- Restart the service after any version change.
- Retest with a simple JSP page to isolate runtime issues from application logic issues.
If the application still fails, the problem may be in the deployment package, web.xml configuration, or external library requirements rather than the runtime alone.
Best practices for avoiding runtime version problems
- Document the exact Java and Tomcat version used in development.
- Keep build and production runtime versions aligned where possible.
- Test upgrades in a staging copy before changing the live service.
- Use dependency versions that are compatible with your selected Java release.
- Review Tomcat logs after every deploy.
- Prefer supported versions over very old or untested combinations.
These practices are especially useful in shared hosting environments with a private JVM, because the application runtime is under your control but still depends on the service configuration in Plesk.
FAQ
Will my JSP application always fail if the runtime version is different?
No. Some applications run correctly across nearby versions, especially if they use standard APIs and modern libraries. However, the risk of errors increases when the difference is large or when the application depends on older, deprecated, or removed features.
What is the most common error message for a Java version mismatch?
UnsupportedClassVersionError is one of the most common signs that the application was compiled for a newer Java version than the runtime supports.
Should I change Java first or Tomcat first?
Check both together. If the app has a documented requirement, match the full runtime stack: Java, Tomcat, and servlet API level. Changing only Java may not fix a Tomcat compatibility issue.
Can I run a JSP app on a newer Java version than it was built for?
Sometimes yes, but not always. The code may run if it uses compatible APIs and libraries. If the app was built for an older environment, test carefully before using a newer runtime in production.
What should I do if I do not know the required version?
Start with the application documentation, then review logs after deployment. If the application came from a vendor or developer, ask for the exact Java and Tomcat versions used during testing. That is the safest way to avoid trial-and-error in the hosting account.
Does My App Server support private JVM hosting for JSP applications?
Yes. The My App Server approach is designed to let you manage a private JVM and Apache Tomcat environment inside your hosting account, which makes it suitable for JSP hosting, servlet hosting, and small to medium Java applications.
Conclusion
When a JSP application expects a different runtime version, the main risk is incompatibility between the application and the Java/Tomcat environment configured in your hosting account. The result can range from minor warnings to complete startup failure. In a Plesk-based managed hosting setup with My App Server, the practical solution is to identify the required version, match the runtime as closely as possible, restart the service, and verify the application through logs and live testing.
For the most stable result, keep Java, Tomcat, and application dependencies aligned with the version used during development. If the app is under your control, rebuilding for the target runtime is often better than relying on an accidental match. If the app is legacy software, a carefully selected compatible runtime inside your hosting service is usually the safest path.