If your JSP application worked before a Java runtime change and now returns errors, does not start, or behaves differently, the most likely cause is a compatibility mismatch between your application, the servlet container, and the new Java version. In managed hosting environments, this is especially common when a Tomcat instance or private JVM is switched through a control panel such as Plesk, because JSP applications depend on both the runtime and the application server configuration.
In a hosting setup with My App Server, you may be running your own Apache Tomcat instance inside your hosting account, with a selected Java version and service controls available from Plesk. This gives you flexibility, but it also means that changing the runtime can affect compilation, class loading, libraries, startup scripts, and application settings. The issue is usually not the hosting platform itself; it is the fact that older JSP code may rely on APIs, bytecode levels, or container behavior that no longer matches the selected Java runtime.
Why JSP applications can break after a Java runtime change
JSP applications are compiled into servlets and executed by a servlet container such as Apache Tomcat. When the Java runtime changes, several things can change at once:
- the Java language level available to the application
- the version of the servlet container and its supported specifications
- the bytecode version required by compiled classes
- the behavior of libraries used by your application
- the default TLS, security, and encoding settings
- the startup environment variables used by Tomcat
Even if the JSP pages themselves are unchanged, the underlying runtime may no longer be able to load a class, compile a JSP, or initialize a framework component. A site that worked under one JVM can fail immediately after switching to another.
Common symptoms after changing Java runtime
After a Java change, JSP applications often show one or more of the following problems:
- HTTP 500 errors on JSP pages
- Tomcat fails to start from Plesk or My App Server
- application deploys but pages remain blank or partially rendered
- class loading errors such as
ClassNotFoundExceptionorNoClassDefFoundError - JSP compilation errors at runtime
- framework startup failures in Spring, Struts, Hibernate, or older libraries
- encoding issues, broken sessions, or unexpected redirects
- errors related to
javaxversusjakartapackage names
If the problem started exactly after the runtime change, that is the strongest sign that compatibility needs to be checked first.
Most common compatibility causes
1. The application was compiled for a different Java version
Java class files are compiled for a specific bytecode level. If your application or one of its libraries was compiled for Java 8, Java 11, or another version, it may not run correctly on a different runtime if the bytecode or APIs are incompatible.
Typical signs include:
UnsupportedClassVersionError- startup failures immediately after deploy
- errors in custom JAR files or third-party libraries
This often happens when a developer builds locally on one JDK and uploads the application to hosting with another runtime selected in the control panel.
2. The servlet container version no longer matches the application
JSP applications depend on the servlet container, not just Java itself. Apache Tomcat versions differ in how they support Java and servlet specifications. If the runtime change also affects the Tomcat version or configuration, an older application may stop working.
For example, an application designed for an older Tomcat generation may rely on legacy configuration, outdated deployment descriptors, or container behavior that is different in newer versions.
3. The application uses removed or restricted APIs
Some Java APIs available in older runtimes are removed, renamed, or restricted in newer versions. Frameworks or custom code that still reference those APIs may fail during startup.
This is especially relevant when upgrading across major Java releases. Code that has not been maintained for several years is more likely to fail after a runtime switch.
4. The web application still uses older javax packages
Many JSP and servlet applications use the older javax.servlet namespace. Newer application server generations and framework releases may expect jakarta.servlet instead. If the application stack is mixed, deployment may fail or work inconsistently.
This issue is common with:
- older JSP/servlet applications upgraded only partially
- libraries compiled against different servlet APIs
- framework versions that are not aligned with the selected Tomcat runtime
5. Third-party libraries are not compatible with the new JVM
Your own code may be fine, but one outdated library can break the application. Common examples include XML parsers, templating engines, database drivers, or security libraries that are no longer compatible with the selected Java version.
If the application starts only until a specific module is loaded, a library compatibility problem is likely.
6. Environment variables or startup options changed
In a managed hosting environment, switching Java may also change:
JAVA_HOMECATALINA_HOME- memory options such as
-Xmsand-Xmx - garbage collector options
- default file encoding
Some applications depend on specific startup parameters. If these are missing or altered, the application may still deploy but not behave correctly.
How to check what changed in your hosting account
If you use My App Server in Plesk, start by checking whether the Java runtime, Tomcat version, or custom app server settings were changed recently. In many cases, the runtime update is intentional, but the application was not tested against it.
Check the selected Java version
Confirm which Java runtime is currently assigned to the application. Compare it with the version used when the site was last working. If the application was built for Java 8 and the account now runs Java 17, that is a strong compatibility clue.
Check the Tomcat version
Verify whether the Tomcat version is the same as before. Some JSP applications need a specific container generation or configuration format. If Tomcat was replaced or reinstalled, the application may need adjustments in deployment descriptors, context settings, or JAR dependencies.
Review the application logs
Logs are the fastest way to identify whether the problem is a runtime mismatch, a missing class, or a startup script issue. In particular, look for:
- Java version errors
- stack traces mentioning unsupported class versions
- library loading failures
- JSP compilation messages
- classpath or permission errors
If your control panel provides access to service logs, check the latest entries immediately after restart. Errors that appear during startup are often more useful than browser-side messages.
Check whether the app was redeployed cleanly
Sometimes the runtime change itself is fine, but stale compiled JSP files or cached class files remain in the application work directory. If the app was not redeployed cleanly, old compiled output may conflict with the new runtime.
A clean redeploy is often necessary after a major Java or Tomcat change.
Practical steps to fix a broken JSP application
Step 1: Roll back to the last known working runtime if possible
If the application is down in production and you need immediate recovery, switch back to the previous Java version or Tomcat setup that was working before. This is the fastest way to restore service while you investigate the cause.
In managed hosting, this is usually the safest first action because it isolates the problem. If the application starts normally again, you have confirmed that compatibility is the issue.
Step 2: Confirm the application’s supported Java level
Check your build files, documentation, or framework requirements. Look for:
pom.xmlor Maven compiler settings- Gradle source and target compatibility
- README or deployment notes
- framework compatibility matrix
- library release notes
Make sure the hosting runtime matches what the application expects. If the app was last tested on Java 8 or Java 11, do not assume it will work on a much newer runtime without verification.
Step 3: Rebuild the application for the new Java version
If you want to stay on the new runtime, recompile the application using the same Java version that the hosting environment now uses. This should include all custom code and any modules that produce JARs or WAR files.
After recompiling, redeploy the updated package and test the application again. This often resolves UnsupportedClassVersionError and related problems.
Step 4: Update incompatible libraries
If the application depends on old libraries, replace them with versions that support the selected Java runtime. Pay special attention to:
- servlet and JSP APIs
- database drivers
- logging frameworks
- XML and JSON libraries
- security and SSL libraries
One outdated JAR can prevent the whole application from starting, even if the rest of the code is fine.
Step 5: Clear generated files and redeploy
After a runtime change, remove old compiled JSP files and temporary application output if your deployment process allows it. Then redeploy the application cleanly.
This helps avoid situations where the container tries to use stale generated code from the previous Java runtime.
Step 6: Review startup options in the control panel
If the application worked before with custom JVM options, compare those options carefully. Memory settings, encoding flags, and system properties can affect application startup and page rendering.
Useful items to verify include:
- heap size settings
- timezone configuration
- file encoding
- proxy or connector settings
- application-specific
-Dproperties
Step 7: Test with a minimal JSP page
If you are not sure whether the problem is with the runtime or the application itself, deploy a simple test JSP page. If the test page works but the main application fails, the issue is likely inside the application code or libraries. If even the test page fails, the problem is probably with the container, runtime, or service configuration.
What to check in My App Server and Plesk
In a hosting platform that supports Java hosting through a Plesk extension such as My App Server, the following checks are especially useful after a Java runtime change:
- verify the selected Java runtime for the app server instance
- confirm which Tomcat version is installed and active
- check whether the service was restarted after the change
- review the application’s deployment path and WAR package
- inspect custom app server configuration if you use a manually uploaded Tomcat
- confirm memory and service limits if the app now starts but stops later
My App Server is designed for practical Java hosting use cases such as JSP hosting, servlet hosting, Tomcat hosting, and private JVM setups for small and medium applications. That means the emphasis is on easy version selection, service control, and deployment management rather than complex enterprise clustering. For most compatibility problems, the important part is simply ensuring that the runtime and application are aligned.
How to prevent this problem in the future
Keep the application and runtime versioned together
Before changing Java in production, record the current runtime, Tomcat version, and major library versions. Keep this information alongside the deployed application version. That makes rollback much easier if the new runtime causes a failure.
Test runtime changes in a staging copy first
If you have a test or staging environment, use it to validate the new Java runtime before applying the change to the live site. Run the same WAR package, same libraries, and same startup options there first.
Use modern and maintained libraries
Applications with current dependencies are usually easier to move between Java versions. Old libraries are the most common source of runtime-related failures in JSP hosting environments.
Document custom JVM settings
If your application depends on specific memory, encoding, or system property values, keep a written record. This helps avoid accidental changes when updating the runtime from the control panel.
When you should contact hosting support
Contact support if:
- the app fails immediately after a runtime change and rollback does not help
- Tomcat will not start from the control panel
- logs show service-level errors rather than application errors
- you need help confirming which Java version is assigned to the app
- your application uses a custom Tomcat installation and the startup behavior is unclear
When you contact support, include the following details:
- the previous working Java version
- the new Java version that was selected
- the Tomcat version in use
- the exact error message from logs
- the application type and framework version
- whether the issue affects all pages or only specific JSP files
Providing these details usually shortens the time needed to identify the compatibility issue.
FAQ
Why did my JSP app work before and fail right after changing Java?
Because JSP applications depend on the Java runtime, servlet container, and library compatibility. A change in any of those layers can expose incompatibilities that were not visible before.
Can I fix the issue by only restarting Tomcat?
Sometimes a restart helps if the problem is stale compiled files or cached classes. However, if the application is truly incompatible with the new runtime, a restart will not solve it.
Does every JSP app need to be rebuilt after a Java change?
Not always, but many applications do. If the app uses compiled classes, third-party libraries, or older framework versions, rebuilding against the new Java version is often required.
What error means the Java version is too new or too old?
UnsupportedClassVersionError is one of the clearest signs. You may also see startup failures or class loading errors when a library or servlet API does not match the runtime.
Is this a hosting problem or an application problem?
Usually it is a compatibility problem between the application and the selected runtime. The hosting platform provides the Java/Tomcat environment, but the application still needs to be compatible with it.
Can I run a custom Tomcat version in a shared hosting account?
In some Java hosting setups, yes. With My App Server, you can install and manage your own Apache Tomcat instance or use prepared versions depending on the account capabilities. The key point is that the application and the runtime must still be compatible.
Summary
A JSP application that breaks after changing the Java runtime is usually affected by version mismatch, outdated libraries, servlet container differences, or startup configuration changes. The fastest fix is to identify the last known working runtime, compare it with the current setup, and confirm that the application was built and tested for the new version. In a managed hosting environment with Plesk and My App Server, this often means checking the selected Java version, Tomcat version, service status, and deployment files, then rebuilding or adjusting the application if needed.
When in doubt, restore the previous working runtime first, then test compatibility carefully before making the change permanent.