If your Tomcat website is still running well, it can be tempting to leave the runtime unchanged. In practice, the right time to upgrade the Java runtime is usually when you need better security, application compatibility, or support for newer Tomcat and library versions. For hosted Tomcat environments, especially when you manage the app through a control panel such as Plesk, upgrading the runtime is often one of the most effective ways to improve stability without changing the application code.
In a managed Java hosting setup like My App Server, you can usually keep your Tomcat application in its own JVM and choose a runtime version that fits the application’s needs. That makes runtime upgrades a normal part of application maintenance rather than a major migration project.
When you should upgrade the runtime
A Tomcat website should be upgraded to a newer Java runtime when one or more of the following apply:
- The current runtime is no longer supported and may receive fewer security fixes.
- Your application or libraries require a newer Java version to run correctly.
- You are preparing for a Tomcat upgrade and the target Tomcat version needs a newer Java release.
- You are seeing compatibility issues with frameworks, dependencies, or build tools.
- You need security and performance improvements available in newer JVM releases.
- Your hosting platform offers a tested runtime version that better matches your app’s stack.
In a shared hosting Java setup, the safest approach is to treat runtime updates as a compatibility decision, not just a version preference. The best runtime is the one your application and its dependencies were built to support.
Why the Java runtime matters for Tomcat websites
Tomcat is the servlet container, but the Java runtime is what actually executes your application code. That means your chosen runtime affects:
- startup behavior
- library compatibility
- memory usage
- security posture
- garbage collection behavior
- support for newer language features
If you host WAR, JSP, or servlet-based applications, the runtime version can determine whether the application starts cleanly or fails with class loading, syntax, or dependency errors. In a control panel environment such as Plesk with a Java hosting extension, runtime selection is often the key setting that keeps the application stable after deploy.
Common signs it is time to upgrade
1. The current Java version is end-of-life or nearing end-of-life
Older runtimes eventually stop receiving public updates. Running an end-of-life runtime increases risk, especially for internet-facing web applications. Even if the application still works, staying on an unsupported version may expose you to security issues and limit future upgrades.
2. Your framework or application requires a newer version
Modern Java frameworks often drop support for older runtime versions. This is common with Spring-based applications, third-party libraries, build plugins, and JSP/servlet dependencies. If a deployment guide or vendor documentation says the app needs Java 11, Java 17, or newer, you should upgrade before deploying that version.
3. You plan to move to a newer Tomcat release
Tomcat versions are tied to Java compatibility. If you want to upgrade Tomcat, check the minimum Java version first. In many cases, the runtime upgrade is required before the Tomcat upgrade, not after it. This is especially important in managed hosting environments where Tomcat is installed as part of a private service.
4. You see startup errors after adding new code or dependencies
Typical runtime-related errors include:
- Unsupported class version errors
- NoClassDefFoundError caused by dependency mismatch
- Illegal reflective access warnings or failures
- Module-related issues after moving to a newer Java release
- JSP compilation problems related to compiler or library compatibility
If these issues appeared after a code change, dependency update, or redeploy, the runtime version should be part of your troubleshooting checklist.
5. You need improved security and patching
Newer Java releases frequently include security fixes and updated crypto, TLS, and certificate handling. For hosted web apps that process logins, forms, or payment-related traffic, this can be a practical reason to upgrade even if the code itself is unchanged.
6. You want better performance or lower memory overhead
New JVM versions often bring improvements in garbage collection, startup time, and runtime efficiency. The benefit may be small for a simple site, but for JSP-heavy or servlet-heavy applications, a newer runtime can help reduce resource usage and improve response consistency.
When you should not upgrade immediately
Upgrading is not always the correct first step. In some cases, staying on the current runtime until you test properly is the safer choice.
- Your application is built on an older framework that has not been validated on newer Java releases.
- You rely on legacy libraries that use removed or deprecated APIs.
- You have a stable production site and no security or support reason to change yet.
- You cannot test the application in a staging environment first.
- The hosting account uses custom application server settings that were tuned for the current runtime.
If your Tomcat site is business-critical, always test the new runtime on a copy of the application before switching production traffic.
How to decide which runtime version to use
The best runtime version is usually the newest version that is confirmed compatible with your application stack. To choose it, check the following in order:
- Application requirements – Review vendor documentation, framework notes, and build settings.
- Tomcat compatibility – Confirm the Tomcat release supports the Java version you want.
- Dependency compatibility – Verify third-party libraries, JDBC drivers, and plugins.
- Build target – Check the Java version used during compilation.
- Hosting support – Confirm the runtime is available in your control panel or can be set manually.
If you manage Java hosting through My App Server, this process is usually straightforward because you can pick from available Java/Tomcat versions or configure a custom app server setup when needed. That gives you flexibility without leaving the shared hosting environment.
Practical upgrade scenarios
Scenario 1: Your app still works, but the runtime is old
If the website runs on an outdated runtime and there is no immediate dependency problem, plan a controlled upgrade. Test the app on a newer supported version, review logs, and check for warnings. This is the best approach when you want to reduce security risk without creating avoidable downtime.
Scenario 2: You are deploying a newer version of the application
If the application release notes mention a newer Java baseline, upgrade the runtime first or at the same time. This is common when moving from older servlet-based builds to newer framework versions.
Scenario 3: Tomcat was updated and the app no longer starts
In this case, the runtime may no longer match the Tomcat version or the application’s expectations. Check the exact Java version, review startup logs, and compare them with the compatibility matrix for the new Tomcat release.
Scenario 4: You are troubleshooting random errors after deployment
If the site started failing after a deploy, runtime mismatch is a strong candidate. Common causes include compiling with a newer JDK than the runtime provides, or using a library that requires a version beyond the one installed on the server.
Step-by-step: how to upgrade safely
1. Identify the current runtime and Tomcat versions
Check the Java version currently used by your Tomcat website and note the Tomcat release. In a Plesk-based hosting environment, this information is typically visible in the Java service settings or application server control section.
2. Review the application’s compatibility requirements
Check:
- the application documentation
- framework release notes
- library compatibility notes
- JDBC driver requirements
- build tool settings such as Maven or Gradle target version
Make sure the new runtime is supported by all important parts of the stack.
3. Check for a matching runtime in the hosting panel
In My App Server, you can often install a ready-made Java/Tomcat version with a button. If the exact version you need is not listed, you may be able to upload or configure a custom runtime and set it manually. Use the simplest supported option first.
4. Test the new runtime in staging or on a copy
Never treat the first runtime switch as a final production change if the application is important. Test:
- login and authentication
- page rendering
- form submission
- file upload or download
- database connectivity
- JSP compilation and error pages
- background tasks or scheduled jobs if used
5. Review logs after startup
After switching the runtime, check the Tomcat logs and application logs for warnings or errors. Pay attention to:
- class loading issues
- deprecated API usage
- SSL/TLS or certificate warnings
- memory allocation problems
- library initialization failures
6. Keep a rollback plan
One of the advantages of a private JVM setup is that you can usually switch back if the newer runtime causes problems. Before upgrading, document the current version and keep a rollback path ready.
How runtime upgrades work in a hosted Tomcat setup
In a traditional server administration workflow, upgrading Java can involve package management, service restarts, environment variables, and manual configuration checks. In a managed hosting setup, the control panel simplifies this process.
With a Java hosting service like My App Server, the runtime is typically tied to the application server instance. This allows you to:
- run your own Apache Tomcat instance
- select an available Java version
- control the service from the panel
- deploy WAR-based applications more easily
- isolate the application from other hosting services in the account
This approach is especially useful for small and medium applications that need a private JVM but do not require complex enterprise clustering or advanced application server orchestration.
Best practices before upgrading
- Read the release notes for both Java and Tomcat.
- Check deprecated APIs used by your application code.
- Verify database drivers and connection pools.
- Confirm deployment descriptors and servlet settings still work.
- Test JSP compilation after the switch.
- Use the same build target as the runtime when possible.
- Monitor memory and CPU usage after deployment.
If your hosting platform supports custom app servers, it is often wise to preserve a known-good configuration while testing the new runtime in parallel.
What happens if you wait too long
Delaying runtime upgrades can lead to a gradual accumulation of risk. The most common problems are:
- older applications becoming harder to redeploy
- dependency upgrades forcing a larger jump later
- reduced security support
- broken compatibility when Tomcat is eventually updated
- more difficult troubleshooting because multiple outdated components change at once
In other words, smaller planned upgrades are usually easier than one large forced migration.
FAQ
How often should I upgrade the Java runtime for a Tomcat website?
There is no fixed schedule for every application, but you should review the runtime whenever Java or Tomcat reaches a new major supported version, or when your application dependencies change. A regular review during maintenance windows is a good practice.
Should I always install the newest Java version available?
No. The newest version is not always the safest choice for a specific application. Use the newest version that is confirmed compatible with your Tomcat release and application stack.
Can an older Tomcat app stop working after a runtime upgrade?
Yes. This can happen if the app uses deprecated APIs, older libraries, or code compiled for a different Java target. That is why testing is important before switching production traffic.
Do I need to upgrade Tomcat and Java at the same time?
Not always. Sometimes only the runtime needs to change, and in other cases Tomcat must be upgraded first or together with Java. Check compatibility documentation before making changes.
What is the safest way to upgrade on hosted Java hosting?
The safest approach is to use a staging copy, test the new runtime, verify logs, and keep rollback access to the previous version. In a control panel environment, this is usually simpler than on a manually managed server.
Does My App Server support private JVM and Tomcat management?
Yes, that is the intended use case. It is designed for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and private JVM use for small and medium applications managed through the hosting panel.
Conclusion
You should upgrade the runtime for a Tomcat website when the current version is unsupported, incompatible with your application, or blocking a Tomcat or framework update. The safest upgrade is the one that matches your application requirements and has been tested before production use.
For hosted environments with Plesk and My App Server, runtime upgrades are usually manageable because you can control the Java/Tomcat version, run a private JVM, and deploy the application with less manual server administration. That makes it easier to keep your Tomcat site secure, compatible, and maintainable over time.