If your JSP site is already running well, the best time to upgrade the runtime is not simply when a new Java release appears, but when your application, framework and hosting setup are ready for it. In a managed hosting environment, especially when you run Tomcat or a private JVM through a control panel such as Plesk, runtime upgrades should be planned around compatibility, security support, and the way your site is deployed.
For most JSP hosting setups, the right upgrade moment is when you need a newer Java feature, your current version is close to end of support, your framework requires it, or you are preparing for a platform refresh. In practice, that usually means testing first, checking servlet and JSP compatibility, and making sure the runtime version matches the application stack rather than upgrading only because it is available.
When a JSP runtime upgrade becomes necessary
A runtime upgrade is usually worth considering when one or more of the following is true:
- Your current Java version is no longer receiving security updates.
- Your web framework, libraries, or application server require a newer Java release.
- You are deploying a new version of your JSP application and want to standardise on a supported runtime.
- You are seeing compatibility warnings during build, deploy, or startup.
- You want to improve performance, memory handling, or TLS support with a newer JVM.
- You are moving from a legacy application to a more maintainable stack.
For a JSP website, the runtime is not just the Java version. It is also the servlet container, usually Apache Tomcat, and the way your hosting account exposes and manages it. In a hosting platform with My App Server, you may have the option to install a ready-made Tomcat and Java version or upload and configure a custom one. That gives you flexibility, but it also means upgrades should be done carefully.
Main reasons to upgrade Java for JSP hosting
Security support has ended or is ending soon
One of the clearest signals to upgrade is when the Java runtime is no longer supported. Even if your JSP site still starts, unsupported Java versions may miss critical security patches. For public-facing websites, that is a real risk, especially if the application handles logins, form submissions, uploads, or personal data.
In a hosted environment, staying on a supported Java version is usually the simplest way to reduce exposure without changing the application architecture. If you are unsure, check whether your current runtime is still receiving updates and whether your Tomcat version is aligned with that Java release.
Your framework or application requires a newer version
Many JSP applications depend on frameworks such as Spring, Struts, Hibernate, or custom libraries that may deprecate older Java versions. A newer build may compile successfully on your development machine but fail on the hosting runtime if the JVM is older than expected.
Common symptoms include:
- Class loading errors at startup
- Unsupported class file version messages
- Missing methods or modules after deployment
- Warnings from build tools about obsolete target levels
If your development team has already moved to a newer Java release, the hosting runtime should usually follow after proper testing.
You need a cleaner deployment path for new releases
Sometimes the upgrade is not about the current site, but about the next release. If you are preparing a new JSP application version and want to avoid future technical debt, upgrading the runtime early can reduce duplicate testing later.
This is especially useful when your hosting account gives you a private JVM or separate Tomcat instance, because you can test the new runtime without affecting other websites on the same account.
You want better performance or platform compatibility
Newer Java versions often bring improvements in garbage collection, startup time, memory use, and TLS support. While a runtime upgrade will not fix every performance issue, it can help with modern application behavior and compatibility with current libraries.
For JSP hosting, performance gains are usually most visible in:
- Application startup
- Memory efficiency under load
- HTTPS and certificate handling
- Background processing and thread management
That said, if your JSP site is small and stable, you should still upgrade because of support and compatibility first, not only performance expectations.
When you should not upgrade immediately
Not every release needs an immediate Java upgrade. In some cases, it is better to keep the current runtime until the application is tested and ready.
Your current application is tied to an older Java version
Older JSP applications sometimes depend on classes, JVM behaviors, or third-party components that are not fully compatible with newer versions. A runtime upgrade can break tag libraries, custom filters, server-side scripts, or deployment descriptors if the application has not been maintained for years.
If the site is stable and business-critical, check compatibility first in a staging environment. Do not assume that a simple redeploy will behave the same way on a newer JVM.
Your Tomcat version is not compatible with the new Java version
Java and Tomcat compatibility must be considered together. A runtime upgrade may require a matching Tomcat upgrade, and not every Tomcat release supports every Java version equally well.
In My App Server, this is important because the control panel may let you choose from ready-made Java/Tomcat combinations or manage a custom app server manually. If you change only the JVM and keep an outdated container, you may create startup problems or subtle runtime bugs.
You do not have a testing copy of the site
If your site is live and you have no staging environment, upgrading directly on production is risky. This is particularly true for JSP sites with custom code, uploaded libraries, or site-specific configuration files.
Before upgrading, make sure you can test the following:
- Application startup
- Login and form flows
- Database connections
- File uploads and downloads
- Background jobs and scheduled tasks
- Error pages and logging
How to decide whether it is the right time
A practical way to decide is to check four areas: support, compatibility, testing, and operational impact. If all four are acceptable, it is usually a good time to upgrade.
1. Check the support status of your current Java version
Look at the Java release you are currently using and confirm whether it is still supported. If it is already past its maintenance window, upgrading should become a priority, especially for internet-facing JSP applications.
2. Check your application requirements
Review the documentation for your JSP application, framework, and build tool. Look for:
- Minimum and recommended Java versions
- Servlet and JSP API requirements
- Tomcat compatibility notes
- Any deprecated dependencies
If your application uses a private JVM or custom app server in Plesk, check the startup scripts and environment variables as well. Sometimes a version change affects more than the application code.
3. Test in a safe environment
Always validate the new runtime before switching production traffic. If your hosting account allows separate service control, use a test instance or a cloned deployment. Run the application, check logs, and verify that the JSP pages render correctly.
In managed hosting, this is one of the biggest advantages of using a separate Tomcat service: you can install or upload a different runtime version and verify behaviour without changing the live configuration immediately.
4. Plan the maintenance window
Even a small runtime upgrade can cause restarts, temporary downtime, or cache rebuilds. If your website is time-sensitive, schedule the change during a low-traffic period. Inform stakeholders if the site handles orders, registrations, or customer logins.
Recommended upgrade approach for JSP hosting in Plesk
In a hosting control panel environment, the safest upgrade path is usually incremental and controlled. A typical approach looks like this:
- Back up the application files, configuration, and database.
- Record the current Java version, Tomcat version, and service settings.
- Review the application’s runtime requirements.
- Install the target Java version or Tomcat package in a test setup.
- Deploy the JSP application and verify startup logs.
- Test key URLs, forms, uploads, and admin functions.
- Confirm memory usage and service stability after restart.
- Switch production only after successful validation.
If you are using My App Server, this workflow fits well because you can manage Apache Tomcat and the JVM from the hosting control panel rather than relying on ad hoc manual changes. For small and medium JSP applications, that often provides the right balance between flexibility and simplicity.
Signs that your current runtime is outdated
You may not always see a direct error, but these signs often indicate that an upgrade should be considered:
- Your deployment pipeline warns about old source or target compatibility.
- You need workarounds for missing APIs or modules.
- Your application logs show deprecation warnings.
- The site uses a framework version that is no longer actively maintained on your current Java release.
- You struggle to install modern third-party libraries.
- Security scanners flag the runtime as unsupported.
If more than one of these applies, waiting too long usually increases the cost of the eventual upgrade.
What to verify before upgrading
Before changing the runtime for a JSP website, verify the following points carefully:
- Java version compatibility: Confirm the application works on the intended JDK or JRE version.
- Tomcat compatibility: Make sure the servlet container supports that Java release.
- Build compatibility: Check source and target levels used during compilation.
- Library compatibility: Review third-party JAR files for version constraints.
- Configuration files: Check context files, server XML, and environment variables.
- Resource limits: Confirm the hosting account limits still suit the new runtime.
- Logging: Ensure startup and application logs are available for troubleshooting.
These checks are especially important in shared hosting with a private JVM, because your JSP website may run independently from the rest of your web stack but still depends on the same account-level limits and service settings.
How My App Server helps with runtime changes
For JSP hosting, My App Server is useful because it gives you a controlled way to work with Java applications inside a hosting account. Instead of treating runtime management as a server-level task only, you can install and manage your own Apache Tomcat or private JVM from the control panel.
This is helpful when you need:
- A specific Java version for one application
- Separate runtime control for different sites
- Easy service start, stop, and restart actions
- Deployment of WAR, JSP, and servlet applications
- A simpler path for testing runtime upgrades
Some versions may be available with one-click installation, while others can be uploaded and configured manually. That makes the platform practical for compatibility-driven upgrades without requiring a full enterprise application server setup.
Practical examples
Example 1: Legacy JSP site on an older runtime
A small business website runs a legacy JSP application on an old Java version. The site works, but the Java release is no longer supported. In this case, the best time to upgrade is after testing the app on a newer runtime and confirming that its libraries still behave correctly.
Example 2: New application release requires a newer JDK
A development team builds a revised JSP application using a newer framework version. The application compiles locally but uses classes not available on the hosting runtime. Here, the runtime upgrade should happen before deployment, not after users begin reporting errors.
Example 3: Tomcat needs alignment with Java
A hosting account uses a separate Tomcat service with a private JVM. The Java version is upgraded, but the Tomcat build is not. Startup issues appear because the container and runtime are not aligned. In this case, both components should be reviewed together, and the upgrade should be staged rather than applied blindly.
FAQ
Should I upgrade the runtime as soon as a new Java version is released?
Not necessarily. For JSP hosting, the best approach is to upgrade when the new version is supported by your application stack, tested successfully, and worth the operational change. Security support and compatibility matter more than simply being current.
What is the safest way to upgrade a JSP runtime?
The safest way is to test on a separate instance or staging copy first, back up the site, check Tomcat compatibility, and switch production only after verifying startup and key user flows.
Can I keep my JSP site on an older Java version if it still works?
You can, but it is not ideal if the version is no longer supported or if your libraries are moving forward. An application that still works today may become harder to maintain later, especially if you delay the upgrade too long.
Do I need to upgrade Tomcat at the same time as Java?
Often yes, or at least you should review them together. Java and Tomcat compatibility is an important part of JSP hosting. A mismatch can cause startup failures or unexpected behaviour even if the application code itself has not changed.
What if my JSP app uses custom libraries or old framework versions?
Test carefully before upgrading. Old libraries may depend on deprecated APIs or JVM behavior that changes in newer Java releases. If the application is business-critical, use a clone or staging environment and review logs after deployment.
How does a private JVM help with upgrades?
A private JVM allows you to control the runtime for a specific application without affecting other hosted sites. This makes it easier to test a Java upgrade, roll back if needed, and keep configuration changes isolated.
Conclusion
You should upgrade the runtime for a JSP website in the UK when the current version is no longer supported, when your application stack requires a newer release, or when you are preparing a tested move to a more compatible and maintainable platform. The right time is usually after checking Java and Tomcat compatibility, validating the application in a safe environment, and planning the change within your hosting control panel workflow.
For managed JSP hosting, a setup such as My App Server can make this process more practical by giving you control over Apache Tomcat, Java version selection, service management, and deployment in one place. That way, runtime upgrades become a planned maintenance task rather than an emergency fix.