If your JSP application expects a different runtime version than the one currently available on your hosting account, the result is usually one of three things: the application may fail to start, it may start with warnings and behave unpredictably, or it may run but break at runtime when it reaches a feature that is not supported by the installed Java or Tomcat version.
In a managed hosting environment, this is one of the most common compatibility issues for JSP, servlet, and WAR-based applications. The good news is that it is usually straightforward to diagnose and fix if you know which part of the runtime does not match: the Java version, the servlet container version, or both.
What “runtime version” means for JSP applications
When a JSP application is deployed, it depends on a runtime stack made up of several parts:
- Java Runtime Environment (JRE/JDK) — the JVM version that executes your code.
- Servlet container — commonly Apache Tomcat for JSP and servlet hosting.
- Framework and library requirements — for example Spring, JSTL, Jakarta EE, or older javax-based components.
- Application build target — the Java language level used when compiling the app.
If any of these layers is too old or too new for the application, compatibility problems can appear. For example, a JSP app compiled for Java 17 will not run correctly on Java 11. Likewise, an application written for older javax.servlet APIs may not be compatible with newer container versions that use jakarta.servlet packages.
What happens when the runtime version does not match
1. The application fails during startup
This is the most visible case. The app deploys, but Tomcat cannot initialize it. Typical causes include:
- Class file version is newer than the JVM supports.
- Required servlet API classes are missing.
- A library expects a Java feature that is not available in the installed runtime.
- The application uses code compiled for a later Tomcat or Jakarta EE level.
Common symptoms include deployment errors, application context startup failures, and stack traces in the logs. In a Plesk-based hosting environment, you will usually see these messages in the application or service logs associated with your My App Server instance.
2. The application starts, but certain pages or functions break
Sometimes the runtime version is close enough for startup, but not fully compatible with the app. In that case:
- JSP pages may render partially or fail on specific tags.
- Servlet requests may return HTTP 500 errors.
- Some libraries may work until a specific code path is reached.
- Session handling, file uploads, or encoding behavior may differ.
This type of problem can be harder to spot because the application appears online, but users encounter errors only in certain features. That is why matching the correct Java and Tomcat versions is important before deployment.
3. The application runs, but performance or behavior changes
Even if your JSP application does not crash, a runtime mismatch can still cause subtle issues:
- Deprecated APIs may behave differently.
- Logging output may change.
- SSL/TLS defaults may differ between Java versions.
- Library compatibility can affect memory usage or request handling.
These issues are especially relevant when moving an application from local development to shared hosting or from one hosting plan to another where the default runtime differs.
Common compatibility scenarios in JSP hosting
Java version is older than the application expects
This is the most frequent mismatch. For example, if your app is built with Java 17 features such as newer language syntax or APIs, it will not run on Java 11 or Java 8. In that case, the JVM cannot interpret the compiled classes, and startup may fail immediately.
Typical indicators:
Unsupported class file major versionClassNotFoundExceptionfor newer librariesNoSuchMethodErrorwhen a method exists only in a later runtime
Tomcat version is older than the servlet/JSP version the app expects
JSP applications also depend on the servlet container. If the app was built for a newer Tomcat release or for Jakarta-based APIs, an older container may not understand the deployment descriptors, annotations, or package names used by the app.
This often happens after migrating an application that was previously hosted on a different environment. A project built for modern Tomcat 9/10 behavior may not work correctly on a much older container.
The application uses javax APIs but the runtime expects jakarta APIs
This is a common breaking change in modern Java web hosting. Older applications use javax.servlet, while newer Jakarta EE based environments use jakarta.servlet. These packages are not interchangeable.
If your app, framework, or library has not been updated for the Jakarta namespace change, it may compile locally but fail when deployed to a runtime that expects the newer API layout.
How to check which runtime version your JSP application needs
Before changing anything in your hosting control panel, confirm the exact requirements of the application. The fastest way is to check these sources:
- Application documentation — look for supported Java and Tomcat versions.
- Build files —
pom.xml,build.gradle, or deployment notes often mention the target version. - Framework requirements — Spring, Hibernate, Struts, JSF, or JSP tag libraries may require a specific runtime.
- Compiled class version — if you have access to the build output, verify which Java release was used.
- Previous working environment — compare it with the current hosting runtime.
If the app was developed by a third party, ask for the minimum supported Java version and the Tomcat version it was tested against. This saves time and avoids trial-and-error deployment.
How My App Server helps in a hosted JSP environment
In ITA’s Java hosting setup, My App Server gives you practical control over the runtime from within Plesk. This is useful when your JSP app needs a specific Java or Tomcat version and you want to manage it without leaving the hosting panel.
With My App Server, you can typically:
- install a ready-made Apache Tomcat version with a button,
- select or adjust the Java runtime used by the application,
- run a private JVM inside your hosting account,
- deploy WAR-based JSP and servlet applications more easily,
- manage service control from Plesk when the application needs a restart.
This model is well suited to small and medium JSP applications that need a dedicated runtime but do not require a large enterprise application server platform. It gives you enough flexibility to match application requirements while keeping administration simple.
What to do if the runtime version is wrong
Step 1: Identify the exact version mismatch
Check whether the problem is with:
- the Java version,
- the Tomcat version,
- the servlet/JSP API level, or
- an application library that depends on one of these.
Look at the error logs first. A Java class version error usually means the JVM is too old. A missing servlet class or package mismatch usually points to Tomcat or Jakarta compatibility.
Step 2: Compare the app requirements with the available runtime
In the hosting panel, verify which runtime is currently active for the application. Compare that with the documented requirements of the app. If the app needs a newer Java version than the one currently selected, you will need to switch to a compatible version or install a different runtime.
Step 3: Switch to a compatible Java version if available
If your hosting plan includes multiple Java versions, choose the one that matches the application. For JSP hosting, this is often the simplest fix. After changing the version, restart the service and test the app again.
Always test the application after switching versions. Some apps run correctly on more than one Java release, but others depend on a very specific version range.
Step 4: Install or select the correct Tomcat version
If the issue is related to the servlet container, choose the Tomcat version that matches the app’s expectations. Applications built for older servlet APIs may require an older container, while newer apps may need a current Tomcat release.
In a Plesk-based environment, this is usually managed through the My App Server extension, where you can install a different Tomcat version or configure a separate instance for the site.
Step 5: Rebuild the application if necessary
If the hosting runtime cannot be changed to match the app, rebuild the application for the available version. This is often the best option for developers who control the source code.
Examples:
- compile the app against the Java version provided by hosting,
- update deprecated libraries,
- replace older javax dependencies if moving to a Jakarta-based runtime,
- redeploy the WAR file after testing locally.
Step 6: Restart the service and clear caches
After changing runtime settings, restart the Tomcat service from the control panel. If the application uses cached JSP pages or framework caches, clear them before testing. This helps avoid false errors caused by old compiled classes or stale session data.
Best practices for choosing the right runtime version
- Match the production runtime early — develop and test with the same Java and Tomcat versions you plan to use in hosting.
- Avoid assuming newer is always better — many JSP applications depend on older APIs or libraries.
- Check both Java and Tomcat — a correct JVM alone does not guarantee servlet compatibility.
- Keep build output consistent — compile against the same target level used in deployment.
- Document version requirements — record them in your project notes for future migrations.
- Test after every runtime change — especially after upgrades or container replacement.
Example: migrating a JSP app to hosted Tomcat
Imagine you have a JSP application that worked on a local server with Java 11 and Tomcat 9. You upload the WAR file to your hosting account, but the application fails during deployment. The log shows a missing class from a newer library or an incompatible servlet package.
In this case, the likely causes are:
- the hosted Java version is different from the local one,
- the Tomcat version does not match the app’s servlet API expectations,
- the application was compiled with a newer or older target level.
The fix may be to select Java 11 in My App Server, install the matching Tomcat version, and redeploy the WAR. If the app was actually built for Java 17, then the host runtime must be upgraded or the app must be rebuilt for the available environment.
How to recognize version mismatch errors quickly
Here are some useful clues from common log messages:
- Unsupported class file major version — compiled with a newer Java version than the JVM supports.
- NoClassDefFoundError — a class expected by the application is missing from the runtime or libraries.
- ClassNotFoundException — a required class cannot be loaded, often because of version mismatch or missing dependency.
- NoSuchMethodError — code was compiled against one library version, but a different version is loaded at runtime.
- Servlet/JSP initialization errors — often point to Tomcat or API incompatibility.
If you see these repeatedly after deployment, the first thing to verify is whether the runtime version matches the application build target.
When to contact hosting support
Contact support if:
- you are not sure which Java or Tomcat version is active,
- the application requires a version not listed in the control panel,
- you need help selecting the correct My App Server instance,
- the service starts but the logs show a compatibility error you cannot interpret,
- you have changed the runtime but the app still behaves as if the old version is used.
When you contact support, include the application name, the current runtime version, the expected version, and the exact error message from the logs. This helps resolve the issue faster.
FAQ
Why does my JSP application work locally but not on hosting?
Local and hosted environments often use different Java or Tomcat versions. Even small differences can cause deployment or runtime errors, especially if the app depends on specific libraries or servlet APIs.
Can I run multiple Java versions for different applications?
In a hosting setup with My App Server, this may be possible depending on your account and configuration. It is useful when different apps require different Java releases. Check the available service options in Plesk.
Is a newer Java version always compatible with an older JSP app?
No. Older JSP applications may rely on deprecated APIs, old libraries, or javax-based components. A newer JVM or Tomcat version can expose compatibility issues.
What is the difference between a Java version problem and a Tomcat version problem?
Java version problems usually involve the JVM and compiled class compatibility. Tomcat version problems usually involve servlet and JSP API support. In many cases, both must match for the application to run correctly.
Should I recompile the app or change the runtime?
If you control the source code, recompiling for the available runtime is often the cleanest solution. If you do not control the code, or if the app was built for a specific runtime, changing the hosted Java or Tomcat version is usually the faster fix.
Conclusion
When a JSP application expects a different runtime version, the main risk is incompatibility between the app and the hosted Java or Tomcat environment. The result can be startup failure, broken pages, or hidden runtime errors. The safest approach is to verify the application’s requirements, compare them with the available hosting runtime, and then either switch the Java/Tomcat version or rebuild the application for the supported environment.
In a Plesk-based Java hosting setup with My App Server, this process is usually practical and manageable: you can select a compatible runtime, run a private Tomcat instance, and deploy your JSP or servlet application with the right version from the start. That saves time, reduces errors, and makes hosting behavior much closer to what the application actually expects.