If your Java application expects a different runtime version than the one currently selected in your hosting account, the application may fail to start, work incorrectly, or show errors as soon as it loads. In a managed hosting environment, this usually means the Java version configured for your app server, private JVM, or Tomcat instance does not match what the application was built and tested against.
With a control panel setup such as Plesk and a Java hosting solution like My App Server, this is often easy to check and correct. The key is to match the application’s required Java runtime version with the version installed or selected for that service. If you use a WAR-based Java app, JSP site, servlet application, or a custom Tomcat setup, the runtime version matters just as much as the application code itself.
What happens when the runtime version does not match
Java applications are compiled and tested for specific runtime versions. If the application expects one version but the server uses another, the result depends on the type of mismatch:
- Older runtime than required – the app may not start at all because it uses classes, methods, or language features that do not exist in that version.
- Newer runtime than expected – the app may start, but some libraries or frameworks may behave differently, warn about unsupported changes, or fail during startup.
- Mixed dependency compatibility – the app may work in one environment and fail in another if a library expects a specific Java version.
Common symptoms include startup errors in Tomcat logs, HTTP 500 errors, deployment failures, class loading problems, or features not behaving as expected. In hosting environments, this is often seen immediately after a redeploy, version change, or migration from another platform.
Why Java version compatibility matters in hosting
Unlike a static website, a Java application depends on the runtime environment every time it runs. The runtime version affects:
- available Java language features and APIs
- compatibility with third-party libraries
- Tomcat and servlet container behavior
- JSP compilation and runtime processing
- startup flags, memory settings, and module access
In a hosting platform that provides a private JVM or managed Tomcat instance through a panel, the selected Java version is part of the application setup. If the application was built for Java 8, but the service is using Java 17, or vice versa, you may need to adjust the runtime or update the app.
Typical error signs you may see
When the runtime version is wrong, you may encounter one or more of the following:
- UnsupportedClassVersionError – the application was compiled with a newer Java version than the runtime supports.
- NoSuchMethodError or NoClassDefFoundError – a dependency expects APIs that are missing or changed.
- ClassNotFoundException – a library or servlet component cannot be loaded correctly.
- Tomcat startup failures – the service may start and stop immediately if the runtime is not compatible.
- JSP compilation errors – JSP pages may fail to compile if the selected runtime does not support the required features.
- Application behaves differently after deployment – the app loads, but pages, forms, or background tasks do not work as before.
If you are using My App Server, these messages are usually visible in the application logs, Tomcat logs, or service output inside the control panel. Checking logs is the fastest way to confirm a version mismatch.
How to identify the Java version your application needs
Before changing anything in the hosting panel, confirm the version required by the application. In many cases, the answer is available from the vendor, framework documentation, or build files.
Check the application documentation
Look for supported Java versions in the project documentation, README files, installation guide, or release notes. Frameworks often list the minimum runtime version required for each release.
Review build configuration files
If you have access to the source code, inspect files such as:
- pom.xml for Maven-based projects
- build.gradle for Gradle projects
- MANIFEST.MF for packaged JAR/WAR details
These files may indicate the target Java release, source compatibility, or plugin settings.
Inspect framework and library requirements
Some common Java frameworks require a specific baseline version. For example, a modern Spring-based application may require a newer runtime, while an older servlet application may only support Java 8. If one dependency requires a higher version than the rest of the app, the highest requirement usually wins.
Check your local development environment
If the application works locally but fails in hosting, compare the local Java version with the version selected in your hosting account. A mismatch between development and production is a common cause of deployment issues.
What to do in My App Server and Plesk
In a managed Java hosting setup, you usually have two practical options: change the runtime version or adapt the application to the version already configured. With My App Server, the goal is to make this process manageable through Plesk, while keeping the app isolated in its own service or private JVM.
Option 1: Select a compatible Java runtime
If your application needs Java 8, Java 11, Java 17, or another available version, choose that version for the service in the control panel. This is the safest option when the application was built and tested against a specific runtime.
Typical steps are:
- Open Plesk and go to the Java application or My App Server service.
- Check the current runtime version used by the app.
- Select the version required by your application, if available.
- Restart the service or redeploy the application.
- Review logs to confirm that startup is successful.
Option 2: Update the application for the installed runtime
If the hosting account already uses a newer Java version and you want to keep it, you may need to update the application code, dependencies, and build settings. This is often necessary when migrating older apps to a newer runtime.
Common changes include:
- updating outdated libraries
- fixing deprecated API usage
- adjusting servlet or JSP dependencies
- rebuilding the WAR with the correct target version
- testing startup and request handling after redeploy
This approach is useful when your app benefits from newer Java features or security updates, but it requires testing before production use.
Option 3: Upload and configure a custom app server
If your application needs a particular Tomcat or JVM setup that is not covered by the standard one-click versions, you may be able to upload and configure a custom app server. This is useful for apps with special startup scripts, non-default libraries, or specific runtime tuning needs.
In that case, make sure the custom server still uses a Java version compatible with your application. A custom setup does not remove the need for version matching; it only gives you more control over how the runtime is deployed.
How to check the runtime version inside the service
If you are not sure which Java version is active, check it from the service itself. Depending on your setup, you may be able to verify it through logs, startup output, or a simple diagnostic page.
Use startup logs
Tomcat and the JVM usually print version information when the service starts. Look for lines that mention the Java version, vendor, or runtime path.
Run a version check page or endpoint
For web applications, you can add a temporary diagnostic page that prints the active Java version. A servlet can display the output of System.getProperty("java.version") and related properties. Remove this page after testing if it is not needed in production.
Check Plesk service details
In hosting control panels, the selected runtime may appear in the application configuration, service settings, or My App Server panel. Confirm that the version shown there matches the version your application requires.
Best practices when choosing a Java runtime version
For a stable hosting setup, follow these guidelines:
- Match the runtime to the application first – compatibility is more important than using the newest available version.
- Keep build and runtime aligned – the version used to compile the app should be compatible with the runtime selected for hosting.
- Test after every version change – even minor updates can affect older libraries or container behavior.
- Check Tomcat compatibility – some Java versions work better with specific Tomcat releases.
- Review third-party dependencies – one outdated library can prevent a newer runtime from working correctly.
- Keep a fallback plan – if a version change breaks the app, know how to revert quickly.
In a managed hosting environment, it is often better to use the version your application was designed for than to force a newer runtime without testing.
Example scenarios
Scenario 1: An older WAR file is deployed on a newer runtime
A customer uploads a WAR file built for Java 8, but the service is configured for Java 17. The application starts, but an old dependency uses an API that was removed or changed. The app throws an error during initialization.
Fix: switch the service to Java 8 if supported, or update the application and libraries to be compatible with Java 17.
Scenario 2: A modern framework requires a newer Java version
A developer deploys an application built with a framework that requires Java 17, but the hosting account is still using Java 11. The app fails immediately with a class version error.
Fix: upgrade the runtime version in the service, then restart and redeploy.
Scenario 3: JSP pages compile locally but not on the server
The application works on a developer machine, but the hosted Tomcat instance shows JSP compilation errors. The runtime on the hosting account is older than the one used during local development.
Fix: align the hosting runtime with the local setup, or rebuild the app for the target version used in hosting.
How version mismatch affects Tomcat hosting
When you use Tomcat hosting, the Java runtime and the servlet container work together. Tomcat itself may run fine, but the deployed web application can still fail if it expects a different runtime version.
Important points to keep in mind:
- Tomcat version and Java version are related, but not the same thing.
- A Tomcat release may require a minimum Java version.
- Your application may require a higher version than Tomcat itself.
- Changing the runtime may require a service restart before the new version is used.
If your app uses JSP, servlets, filters, listeners, or background jobs, verify both the container and the JVM version after every change.
Practical troubleshooting checklist
If your Java application expects a different runtime version, use this checklist:
- Confirm the Java version required by the application.
- Check the version currently selected in Plesk or My App Server.
- Review Tomcat and application logs for version-related errors.
- Compare local development and hosted runtime versions.
- Switch to a compatible Java version if available.
- Restart the service and redeploy the WAR or app files.
- Test key pages, login flows, forms, and background tasks.
- If needed, update dependencies and rebuild the application.
When to change the application instead of the runtime
Sometimes the simplest fix is to change the app, not the hosting version. This is usually the better option when:
- the required Java version is no longer supported by the application vendor
- you want to standardize on a newer runtime for future maintenance
- the app uses outdated libraries that should be upgraded anyway
- you are migrating from an old server environment to a newer hosting setup
However, if the application is stable and only needs one specific Java version, switching the hosting runtime may be the fastest and safest solution.
FAQ
Will my Java application always break if the runtime version is different?
Not always. Some applications can run on more than one Java version. Problems usually appear when the app depends on features or libraries that are not compatible with the selected runtime.
What is the most common error for a Java version mismatch?
One of the most common errors is UnsupportedClassVersionError. This usually means the application was compiled for a newer Java version than the one currently used by the server.
Can I run different Java applications with different versions in one hosting account?
That depends on the hosting platform and how the service is configured. In a setup with private JVM or separate app server instances, this may be possible if the control panel allows version selection per service.
Should I always choose the newest Java version available?
No. The best choice is the version required by your application and its libraries. Newer is not automatically better if the app was not built for it.
Do I need to restart Tomcat after changing the Java version?
Yes, in most cases. The application or service must restart so the new runtime can be loaded and used by the container.
What if my app vendor does not specify a Java version?
Use the version recommended by the framework or library stack, then test carefully. If no documentation is available, check the build files or contact the developer before deploying to production.
Conclusion
When a Java application expects a different runtime version, the result is usually a startup error, dependency issue, or unstable behavior. In hosting environments that provide Tomcat and private JVM control through Plesk, the fix is typically to align the selected Java version with the application’s requirements.
The safest approach is to confirm the required runtime, compare it with the current hosting setup, and then either switch the Java version or update the application to match. With My App Server, this process is practical for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM hosting where version control matters for everyday deployment and maintenance.
For reliable operation, always test after changing the runtime, review logs carefully, and keep the application and hosting configuration in sync.