When a JSP application stops working after a Java runtime change, the cause is usually a version mismatch between the application, the servlet container, and the JDK used to run it. In a hosted environment, this often happens after switching the Java version in Plesk or after moving the application to a different Tomcat or private JVM setup. Even a small runtime change can affect compilation, library loading, class compatibility, and how the container starts the web application.
In Java hosting environments such as My App Server, JSP sites are typically deployed on Apache Tomcat or another private JVM instance. That gives you flexibility, but it also means the application depends on the exact Java version and the startup configuration that was selected. If those settings change, a JSP application that worked before may fail with HTTP 500 errors, compilation errors, missing classes, or startup loops.
Why a Java runtime change can break JSP applications
JSP applications are not only plain static files. They are compiled at runtime into servlet classes, and those classes run inside a specific Java and Tomcat combination. If you change the runtime, you may change one or more of the following:
- the Java language level supported by the JVM
- the servlet and JSP API version expected by the application
- the bytecode level used by precompiled libraries
- the way third-party dependencies are loaded
- system properties, encoding, and security defaults
- the location of the Java installation used by Tomcat
These differences can be enough to stop the application from starting or compiling correctly. A JSP app may appear healthy immediately after deployment, then fail only when a page is first requested and Tomcat tries to compile the JSP into a servlet.
Most common symptoms after changing Java runtime
If your JSP application is broken after a Java version change, you will often see one of these signs:
- HTTP 500 Internal Server Error on JSP pages
- ClassNotFoundException or NoClassDefFoundError
- UnsupportedClassVersionError
- JSP compilation errors after the first page request
- Tomcat fails to start or restarts repeatedly
- the application starts, but specific features stop working
- encoding problems, date parsing issues, or unexpected runtime behaviour
In hosted Tomcat or private JVM setups, the real cause is usually visible in the application logs, not on the browser page itself. The browser only shows a generic error while the container logs explain which class, method, or library failed.
Typical compatibility reasons
Java version is too new for the application
Older JSP applications are often built and tested against an older JDK. If you switch to a newer Java runtime, the application may rely on APIs, deprecated security settings, or container behaviour that changed in the newer release. This is especially common with older frameworks, legacy tag libraries, and custom classes compiled many years ago.
Java version is too old for the application or libraries
Some modern libraries require a newer Java runtime. If you move the application to an older JDK, Tomcat may still start, but the application can fail when it loads a dependency compiled for a higher class file version.
Tomcat and Java are not aligned
JSP hosting depends on both the JVM and the servlet container. A Tomcat version may support a range of Java versions, but not every combination is equally safe for every application. If you use a private JVM in My App Server, make sure the Tomcat build and the selected Java runtime are compatible with the application stack.
Precompiled classes were built for another Java level
If your application includes compiled .class files, JARs, or a prebuilt WAR package, those files may have been compiled for a different Java version than the one currently selected. The JVM then rejects the class files before the application can run normally.
Framework or library incompatibility
Many JSP applications use Spring, JSTL, Hibernate, older JDBC drivers, XML parsers, or application-specific libraries. A runtime change can expose an incompatibility in one of these dependencies. For example, a JDBC driver may no longer match the installed Java version, or a library may use internal classes that are not available in the new runtime.
Container configuration changed during the update
In a managed hosting panel, changing Java may also reset or affect environment variables, startup options, heap size, context settings, or the path to the selected JVM. If Tomcat starts with a different configuration than before, the application may fail even if the code itself did not change.
What to check first in Plesk or My App Server
Before changing the application code, verify the hosting configuration. In a Plesk-based Java hosting environment, these checks usually solve the problem faster than rebuilding the app immediately.
- Confirm the selected Java version. Check whether the application is now running on the expected JDK version.
- Check the Tomcat version. Make sure the servlet container still matches the application requirements.
- Review the service status. Verify that the My App Server service is running normally and did not stop after the change.
- Inspect the application logs. Look for stack traces, class loading errors, and JSP compilation messages.
- Check deployment mode. Confirm whether the app is deployed as a WAR, expanded directory, or custom app server setup.
- Review startup parameters. Ensure memory settings and Java options were not altered unexpectedly.
If your hosting plan allows a private JVM, Tomcat may start with a version different from the system default. That is useful for compatibility, but it also means you must verify the runtime used by the service itself, not only the one shown in the panel.
How to diagnose the problem step by step
1. Identify the exact Java version before and after the change
Note the previous JDK version and the current one. Even small jumps such as Java 8 to Java 11, or Java 11 to Java 17, can affect JSP applications. If the application was created long ago, it may depend on deprecated APIs or libraries that no longer behave the same way.
2. Check the first error in the log
Do not stop at the final HTTP 500 message. The first error in the logs is usually the real cause. Common log entries include:
- UnsupportedClassVersionError
- ClassNotFoundException
- NoSuchMethodError
- JasperException during JSP compilation
- java.lang.NoClassDefFoundError for a library class
If the error appears only on the first request to a JSP page, the problem may be compilation-related. If the application fails before any request, the issue is probably in startup or dependency loading.
3. Confirm the application’s supported Java level
Check the documentation of the application, framework, or WAR package. Many older JSP apps were designed for Java 6, 7, or 8. Running them on a newer JVM is sometimes fine, but not always if the app uses outdated dependencies or container internals.
4. Rebuild the application if needed
If you have access to the source code, rebuild the application using the same or newer Java level that the host now uses. This is especially important if you deploy precompiled classes or a custom library set.
5. Test with a clean deployment
Old compiled JSP classes or cached container files can sometimes cause repeated failures after a runtime switch. Removing the exploded application and redeploying the WAR can help eliminate stale artifacts.
6. Verify the JDBC driver and external libraries
Database drivers and third-party JAR files are a frequent source of compatibility issues. Make sure they are still supported by the selected Java version and Tomcat release.
Practical fixes that often work
Switch back to the previous Java version
If the application worked before the change, the fastest recovery is often to return to the last known good Java runtime. In My App Server, this is usually the simplest way to restore service while you investigate the dependency issue.
Update the application for the new runtime
If you need to stay on the new Java version, update the code and libraries. This may include:
- recompiling the application
- upgrading outdated dependencies
- replacing unsupported JDBC drivers
- fixing deprecated API usage
- adjusting JSP tag libraries or servlet imports
Use the correct Tomcat version for the app
Some applications are sensitive not only to Java but also to the Tomcat generation. A supported Tomcat version reduces the risk of JSP parser changes, servlet API mismatches, and startup issues. If your hosting platform offers several ready-to-install versions, choose the one that best matches the application’s original stack.
Clear cached JSP and temporary files
After a Java switch, stale compiled JSP files can continue to cause errors. Clear Tomcat temp directories and redeploy the application so JSPs are recompiled under the current runtime.
Check file and directory permissions
Runtime changes sometimes coincide with service restarts or deployment changes that affect permissions. Make sure the Tomcat process can read the application files, write temporary files, and create logs if needed.
Working with My App Server in a shared hosting account
With My App Server, you can run a private JVM and manage your own Apache Tomcat instance inside a shared hosting account. That is useful for JSP hosting and servlet hosting because it gives you more control over the Java runtime without requiring a separate dedicated server.
To reduce breakage after a runtime change, follow a stable deployment process:
- change only one variable at a time
- keep a record of the previous Java version
- test the app after every Java or Tomcat switch
- verify logs before making additional changes
- rebuild the WAR if the application was compiled for another JDK
This approach is especially helpful when using a private JVM, because the application may behave differently from the system-wide Java installation. Managing the service through Plesk makes it easier to restart, switch versions, and confirm which runtime is active.
How to prevent the issue in the future
The safest way to avoid broken JSP deployments after a Java runtime change is to treat Java version updates like application changes, not like routine cosmetic updates.
- test the new Java version on a staging copy first
- check compatibility of your JSP framework and libraries
- document the Java version used for each live application
- keep backups before changing runtime settings
- prefer supported, current library versions over outdated JAR files
- monitor logs after any Tomcat or Java switch
For older applications, it is often best to keep the same runtime until you can verify that every dependency works correctly on the new platform.
Example scenarios
Example 1: JSP pages compile on demand, then fail
A site deploys successfully, but the first visit to a JSP page returns a 500 error. The log shows a JSP compilation failure. In this case, the problem is likely a classpath or runtime compatibility issue, not a deployment failure. Rebuilding the app and checking JSTL or servlet JAR versions usually helps.
Example 2: The app starts on Java 8 but not on Java 17
The application uses older dependencies and an outdated JDBC driver. After the Java switch, Tomcat starts but the app throws NoClassDefFoundError. The fix is usually to update the dependencies or temporarily return to Java 8 if the application cannot yet be modernised.
Example 3: Tomcat starts, but one feature is broken
The home page works, but login or file upload fails after the runtime change. That often means a library, encoding setting, or security-related API changed in the new Java runtime. The application may need a code update or a configuration adjustment in the Tomcat service settings.
FAQ
Why did my JSP app work before the Java change?
It worked because the previous Java version and Tomcat setup matched the application’s compiled classes and dependencies. After the change, one or more compatibility assumptions no longer applied.
Can I keep the same application and just change Java?
Sometimes yes, but not always. If the app uses outdated libraries or was compiled for a different Java version, it may need to be rebuilt or updated before it can run correctly on the new runtime.
Is this a Tomcat issue or a Java issue?
It can be both. Java controls the runtime, while Tomcat controls how JSPs are compiled and executed. A problem may appear after a Java change, but the underlying failure could still involve Tomcat, libraries, or deployment files.
Should I delete the application and redeploy it?
Yes, if the issue started after a runtime change and you suspect stale JSP caches or compiled files. A clean redeploy often resolves temporary compatibility problems.
What if I do not know which Java version the app needs?
Check the application documentation, inspect the build files if available, and review the logs for class version errors. If the application is legacy software, test it on the previous working Java runtime first.
Conclusion
A JSP application that breaks after a Java runtime change is usually suffering from version incompatibility, dependency mismatch, or stale compiled files. In hosted Java environments such as Plesk with My App Server, the best approach is to verify the selected Java version, check Tomcat logs, confirm application requirements, and redeploy the app cleanly if needed. If the application was built for an older runtime, the safest short-term fix is often to return to the last known good Java version, then plan a controlled upgrade of the application stack.
When you manage your own private JVM and Tomcat instance, small configuration changes can have a big effect. A careful version check, clean deployment, and log-based troubleshooting usually restore JSP service quickly and help prevent the same issue from happening again.