If your Java application expects a different runtime version than the one currently selected on your hosting account, the application may fail to start, behave unpredictably, or throw compatibility errors at runtime. In a managed hosting environment with Plesk and a Java service such as My App Server, this usually means the application was built for one Java release but is being executed on another.
The outcome depends on whether the runtime is newer or older than the version the application was designed for. A small version gap may work fine, but a major mismatch can break classes, libraries, frameworks, or even the Tomcat startup process itself. For JSP hosting, servlet hosting, and private JVM hosting, choosing the correct Java runtime is one of the most important steps before deployment.
What a Java runtime mismatch means
A Java application does not just need “Java” in general. It usually expects a specific runtime version, such as Java 8, Java 11, Java 17, or another release supported by the application stack. That expectation can come from:
- the application itself
- a framework such as Spring, Struts, or Hibernate
- the build tool or deployment package
- the Tomcat version used by the application
- libraries compiled with a newer or older bytecode level
If the runtime does not match, the application may still upload successfully to the hosting account, but it can fail during startup or when specific features are used.
What can happen if the runtime version is wrong
The exact symptom depends on the direction of the mismatch. In practice, hosting teams often see one of these situations.
If the app expects a newer Java version
This is the most common case. For example, an application compiled for Java 17 will not run properly on Java 11 or Java 8.
- Tomcat may start, but the web application fails to deploy.
- The JVM may throw class format errors.
- Missing methods or APIs can cause startup exceptions.
- Framework components may stop working after deployment.
Typical error messages include:
UnsupportedClassVersionErrorNoSuchMethodErrorClassNotFoundExceptionfor version-specific dependencies- deployment failure in the application logs
If the app expects an older Java version
Older applications can also fail when run on a much newer runtime, especially if they depend on removed APIs, deprecated libraries, or old application-server behavior.
- The application may start but show errors on certain pages or functions.
- Legacy libraries can behave differently on newer JVMs.
- Some old XML, security, or reflection-based code may fail.
- The application may need updated dependencies before it can run safely on the newer runtime.
In many cases, running older code on a newer Java version is possible only after testing and dependency updates.
If Tomcat and the application expect different compatibility levels
In Java hosting, the runtime version and the application server version are closely connected. A Tomcat release supports a defined range of Java versions. If your application expects a specific Java level but the selected Tomcat build was installed for a different one, the issue may appear as a deployment failure or service startup problem.
With My App Server, this matters because you can manage the Java/Tomcat stack directly in Plesk and choose a version that matches your application requirements as closely as possible.
Common signs of a Java version mismatch
If you are not sure whether the runtime version is the problem, look for these signs during deployment or after a restart:
- the application deploys, but the URL returns a 500 error
- Tomcat starts, but the app context is missing
- logs mention unsupported class versions
- the application works locally but not on hosting
- specific pages fail after login or form submission
- builds created for one Java release fail in a different runtime
In managed hosting, the first place to check is the service logs and application logs in Plesk. They usually show whether the problem is linked to bytecode compatibility, a missing dependency, or a library that no longer works with the selected Java version.
Why version compatibility matters in hosting
On a local machine, developers often have multiple JDKs installed and can switch between them quickly. In a hosting account, the selected runtime is part of the service configuration. That means the application must match the version chosen in the control panel or configured for the private JVM.
Version compatibility is important because:
- Java bytecode is compiled for a target version
- frameworks may require a minimum runtime
- Tomcat itself has version requirements
- older libraries may break on newer releases
- security updates can change runtime behavior
This is why choosing the right runtime version is not just a technical detail. It is a deployment requirement.
How My App Server helps you match the runtime version
ITA’s My App Server is designed for practical Java hosting inside a shared hosting account. Through the Plesk extension, you can install and manage your own Apache Tomcat or private JVM and select from several ready-made Java/Tomcat versions.
This makes it easier to:
- choose a runtime that matches your application stack
- deploy WAR, JSP, and servlet applications
- restart or control the service without leaving Plesk
- test a compatible Java version before moving to production
- upload and configure custom application server setups when needed
If a version is not available as a one-click install, you can still upload and configure some custom Java/Tomcat combinations manually, depending on the service limits and compatibility requirements.
How to check which Java version your application needs
Before changing the runtime on your hosting account, identify the expected version as accurately as possible. Use the following checks.
Check the application documentation
The safest source is the official documentation or release notes. Look for statements such as:
- minimum Java version
- supported Java releases
- compatible Tomcat versions
- framework-specific requirements
Inspect the build configuration
If you have access to the source code, check the build files. Maven, Gradle, or Ant projects often declare the target runtime level. For example, the project may be compiled for Java 8 while also being tested on Java 11.
Review the class file target
If you only have the built application, the class file version can reveal what Java release was used during compilation. A mismatch here often explains deployment failures in hosting.
Look at framework requirements
Modern frameworks often set the minimum version indirectly. For example, a framework upgrade may require Java 17 even if the application itself does not.
Test the application locally first
If possible, run the application locally with the same Java version that is available in hosting. If it fails locally, the runtime mismatch is likely the cause rather than the hosting platform.
How to fix a runtime version mismatch
The right fix depends on whether you can change the application or need to change the hosting runtime.
Option 1: Change the runtime to match the app
This is usually the fastest option when the hosting panel supports multiple Java versions.
- Open Plesk and go to the My App Server section.
- Check which Java/Tomcat versions are available for your account.
- Select the version required by the application, or the closest supported version.
- Restart the service if needed.
- Redeploy the application and test it again.
This approach works well when the application was built for a specific runtime and does not need code changes.
Option 2: Rebuild the application for the available runtime
If the hosting environment provides a fixed runtime level and your project can be recompiled, adjust the build target to match the selected Java version.
This may require:
- changing the compiler target in Maven or Gradle
- updating dependencies to versions compatible with the selected runtime
- replacing deprecated APIs
- retesting the application on the new runtime
This is often the better long-term solution if you plan to keep the application on the same hosting account for a while.
Option 3: Upgrade or replace incompatible libraries
Sometimes the main application code is fine, but a third-party library prevents startup on the selected Java version. In that case, update the library first and then redeploy the application.
This is common with:
- old XML parsers
- legacy servlet libraries
- outdated logging frameworks
- older ORM or utility packages
Option 4: Keep a separate runtime for legacy applications
If you host more than one Java application, each one may need a different runtime version. A private JVM or separate Tomcat instance can help isolate one application from another, especially when one app is modern and the other is legacy.
This is one of the practical advantages of Java hosting with service control in Plesk: you can match the runtime to the application instead of forcing every project into the same version.
What to do in Plesk when the app fails after a version change
If you changed the runtime and the application no longer works, use a simple rollback and testing approach.
- Check the application and service logs.
- Confirm the Java version currently selected in My App Server.
- Compare it with the version required by the application.
- Switch back to the previous runtime if the app was working before.
- Restart the service and test again.
If the old version works and the new one does not, the issue is likely compatibility rather than deployment corruption.
Best practices for choosing a runtime version
To avoid problems later, use the following checklist before deploying any Java application to hosting.
- Match the runtime to the application’s documented minimum version.
- Use a Tomcat version that supports the chosen Java release.
- Test the application on the same Java version before upload.
- Avoid switching runtime versions without checking dependency compatibility.
- Keep a copy of the working configuration for rollback.
- Review logs after every version change.
If the application is still under active development, define the target Java version early and keep builds consistent across local, staging, and hosting environments.
Examples of typical compatibility scenarios
Example 1: Java 8 application deployed on Java 17
An older application compiled for Java 8 may start on Java 17, but a deprecated dependency could fail during startup. The fix is usually to update the dependency or test the app on the exact supported runtime before deployment.
Example 2: Java 17 application deployed on Java 11
This often fails immediately with a class version error because the bytecode was compiled for a newer release. In this case, switching the runtime to Java 17 is the correct fix.
Example 3: Legacy JSP app with outdated libraries
The application may still run on a newer Tomcat build, but a few old helper libraries break during requests. Updating the libraries and verifying the servlet API version usually resolves the issue.
When to contact hosting support
Contact support if you have already confirmed the expected runtime version and still cannot start the application. This is especially useful when:
- the selected Java version is correct, but the app still fails
- Tomcat starts and stops repeatedly
- you need help identifying the matching version in My App Server
- a custom application server setup needs manual verification
- the logs point to a service issue rather than an application issue
Provide the Java version, Tomcat version, deployment package type, and the relevant log messages. That information speeds up troubleshooting.
FAQ
Can a Java application run on a different runtime version than the one it was built for?
Sometimes yes, but not always. Minor differences may work, while major version gaps often cause errors. Always test before relying on cross-version compatibility.
What is the most common error for a Java version mismatch?
UnsupportedClassVersionError is one of the most common errors when the application was compiled for a newer Java release than the one installed on the hosting account.
Should I always use the newest Java version available?
No. The safest choice is the version required by your application and its dependencies. Newer is not automatically better if the app was built for an older runtime.
Can I change the Java version in Plesk?
In a setup with My App Server, you can typically select from available Java/Tomcat versions or manage a private JVM from the hosting control panel, depending on the service configuration.
What if my app needs a Java version that is not listed?
If the version is not available as a ready-made install, you may need a custom configuration or a rebuild of the application for a supported runtime. Check the service limits and compatibility requirements first.
Is this mainly relevant for WAR, JSP, and servlet applications?
Yes. Runtime matching is especially important for WAR deployments, JSP hosting, servlet hosting, and applications running inside Tomcat or a private JVM.
Conclusion
When a Java application expects a different runtime version, the result can range from minor warnings to complete deployment failure. The safest approach is to match the Java version, Tomcat version, and application dependencies before going live. In a hosting environment with Plesk and My App Server, this is practical because you can select from available Java/Tomcat versions, manage the service, and keep the runtime aligned with the application’s requirements.
If you see compatibility errors after deployment, check the logs first, confirm the expected Java release, and then either switch the runtime or rebuild the application for the version supported by your hosting setup. A careful version match saves time, reduces downtime, and makes Java hosting much more predictable.