Before switching a Java runtime version, test the change in a controlled way rather than updating the live environment first. A runtime change can affect your application startup, framework compatibility, servlet container behaviour, database drivers, TLS settings, file handling, and even small details such as default encoding or garbage collection behaviour. In a hosting control panel environment such as Plesk, where a Java application may run on its own private JVM or Apache Tomcat instance, the safest approach is to validate the new version against your existing deployment before you switch it for production use.
If you manage Java hosting through a panel extension such as My App Server, the goal is to confirm that the application still deploys, starts, serves requests, and performs correctly after the runtime change. This is especially important for WAR, JSP, and servlet applications that rely on Tomcat configuration, custom startup parameters, or third-party libraries.
What should be checked before changing the Java runtime version?
Test the application in four areas: compatibility, startup, runtime behaviour, and operational control. A version upgrade may look successful if Tomcat starts, but the application can still fail later because of a dependency conflict or a change in JVM defaults.
1. Application and framework compatibility
Start by checking whether your application framework supports the target Java version. This includes Spring, Spring Boot, Hibernate, JSF, Struts, Vaadin, and any internal framework code. Review the minimum and maximum supported Java versions in the framework documentation and verify whether your exact application stack is compatible.
- Check the framework release notes for supported Java versions.
- Review any build tool settings in Maven or Gradle.
- Confirm compatibility of plugins, annotation processors, and code generators.
- Check whether your application still uses deprecated Java APIs removed in newer releases.
For Tomcat hosting, also confirm that your servlet specification version and Tomcat version remain aligned with the Java runtime you want to use. Some older Tomcat releases do not work well with newer Java versions, while some modern frameworks require a newer JVM than the one currently installed.
2. Third-party library compatibility
Libraries can be the hidden source of runtime issues. A dependency may compile successfully but fail at runtime if it relies on internal JDK classes, old TLS defaults, or reflection-based access that is restricted in newer Java versions.
- Test database drivers such as MySQL, MariaDB, PostgreSQL, Oracle, or SQL Server drivers.
- Check libraries used for XML, JSON, logging, mail, PDF generation, and SSO.
- Verify any native or JNI-based dependencies.
- Confirm that logging frameworks like Logback, Log4j, or JUL bindings still behave as expected.
If your hosted Java application connects to external services, test those integrations as part of the runtime change. A new Java version may enforce newer security defaults that affect HTTPS, certificate validation, or weak cipher support.
3. Build and packaging process
Before switching the runtime on the server, make sure the application is built correctly for the target version. The compiled bytecode level, source compatibility, and packaging process must match the runtime you plan to use.
- Confirm the compiler target is compatible with the new Java version.
- Rebuild the application from source using the same version you plan to deploy.
- Check whether the WAR file includes any outdated classes compiled for an older baseline.
- Validate resource filtering, profile-based configuration, and environment-specific properties.
In managed hosting, a common mistake is to keep using an old build artifact that was produced for another Java baseline. Even if the new JVM can run it, the application may not behave correctly because of changed APIs or dependency versions.
How to test a Java runtime switch safely in Plesk or My App Server
In a hosting control panel environment, the safest method is to clone the current setup, apply the new Java version to the test copy, and compare the behaviour with the live site. If you use My App Server, you can typically keep the application isolated within its own Tomcat instance or private JVM, which makes this kind of testing more practical.
Step 1: Record the current working configuration
Before making any change, document the existing setup so you can compare it later if needed.
- Current Java version and vendor.
- Tomcat version and startup parameters.
- JVM memory settings, such as heap limits and metaspace values.
- Application context path, deployment location, and environment variables.
- Database connection settings and any external service endpoints.
This is useful not only for troubleshooting, but also for rollback. If the new runtime causes problems, you can restore the known working configuration without guessing what changed.
Step 2: Create a staging or test copy
Use a separate staging domain, subdomain, or application instance if possible. A test environment should mirror the live setup as closely as possible, including the same app server type, the same Tomcat version, and the same dependencies. Only the Java runtime should change.
If your hosting plan supports multiple Java/Tomcat versions through My App Server, install the target version in a test instance first. This is the best way to see whether the application starts cleanly and whether the selected runtime is appropriate for the app.
Step 3: Switch only one variable at a time
When testing compatibility after changes, avoid changing the Java version, Tomcat version, application code, and config files all at once. If too many variables change together, you will not know which one caused the issue.
- First test the new Java runtime with the existing application package.
- If that works, then test any necessary library updates.
- Only after that should you consider configuration tuning, such as memory settings.
This method gives clear results and makes troubleshooting much faster.
Step 4: Verify startup logs carefully
After the runtime switch, inspect the startup output from Tomcat or the private JVM. A successful start message is not enough on its own. Look for warnings about illegal reflective access, deprecated options, missing modules, encoding changes, or classpath conflicts.
- Check catalina logs and application logs.
- Look for stack traces during startup and shutdown.
- Pay attention to warnings about unsupported JVM flags.
- Confirm the app server starts consistently after a restart.
Some changes only appear under load or after a restart, so test more than once.
Runtime behaviour tests to run after the version change
Once the application starts, test the features that matter most to users and administrators. The objective is not only to prove that the app is “up”, but to confirm that it behaves correctly under the new runtime.
Basic request and response testing
Open the main pages, API endpoints, and any upload or login flows. Test these scenarios with realistic data rather than only a homepage check.
- Home page and key landing pages.
- Authentication and session management.
- Forms, uploads, and file downloads.
- REST endpoints and AJAX calls.
- Redirects, cookies, and CSRF-protected actions.
For JSP and servlet hosting, verify that request routing still works, the context path is correct, and all dynamic content renders without errors.
Database and transaction testing
Database access is one of the most common failure points after a Java version change. Test connection pooling, query execution, transaction boundaries, and any scheduled jobs that interact with the database.
- Connect to the database and confirm the pool initializes correctly.
- Run read and write operations.
- Check for timeouts, connection resets, or SSL handshake failures.
- Verify timezone handling and date parsing.
If your application uses an ORM layer, test lazy loading, entity conversion, and schema migration tools as well.
Security and TLS checks
New Java versions may change default security providers, certificate handling, or protocol support. This can affect outbound HTTPS calls, internal service connections, and user-facing secure endpoints.
- Test HTTPS requests to external APIs.
- Verify certificate trust chains.
- Check whether older TLS versions or weak ciphers are still required by any dependency.
- Make sure session cookies and secure headers still behave as expected.
If you host the app behind Apache or a reverse proxy, confirm that the proxy-to-Tomcat communication still works correctly after the runtime update.
File system and permissions checks
A Java runtime switch can change how the application reads files, writes logs, handles temporary files, or accesses uploaded content. In a managed hosting environment, confirm that the application still has the expected access to its directories.
- Upload and download a file.
- Test export and report generation.
- Check log file creation and rotation.
- Verify temporary file cleanup.
Also check that the application still respects your hosting account’s file permissions and paths after restart.
Performance and resource checks
Different Java versions can change memory usage, startup time, garbage collection behaviour, and peak throughput. Even if the application works functionally, the new runtime may require tuning before it is suitable for regular use.
Memory usage and JVM settings
Review heap size, metaspace settings, and any custom JVM flags. Some flags that were valid in older Java versions are ignored or rejected in newer releases.
- Check whether startup succeeds with the current JVM options.
- Review memory consumption during normal traffic.
- Test peak load scenarios if your application has busy periods.
- Look for out-of-memory warnings or excessive garbage collection.
In a private JVM setup, stable memory settings are important because hosting resources are shared and need to be used efficiently.
Startup and restart behaviour
A runtime switch should not only work once. Restart the app server several times and confirm the service comes back cleanly. This is important for updates, maintenance, and emergency recovery.
- Stop and start the application service.
- Restart Tomcat and verify deployment remains intact.
- Check whether the app comes up automatically after a control panel action.
- Confirm that session persistence works if your application expects it.
What to compare before and after the switch?
Use a simple before-and-after comparison to measure the impact of the change. This helps determine whether the runtime change is safe enough for production use.
| Area | What to compare | What indicates a problem |
|---|---|---|
| Startup | Time to start, log warnings, service status | Longer boot time, crashes, repeated restarts |
| Requests | Page rendering, API responses, redirects | 404, 500, broken sessions, missing assets |
| Database | Connection pooling, CRUD actions, transactions | Driver errors, SSL failures, timeouts |
| Security | HTTPS calls, certificate validation, auth flows | Handshake failures, trust errors, login issues |
| Performance | Response time, memory use, CPU spikes | Slower pages, high memory pressure, GC pauses |
Common problems after changing Java versions
Some issues appear repeatedly after runtime upgrades. Knowing them in advance can save time during troubleshooting.
Unsupported JVM flags
Older startup parameters may no longer exist or may behave differently. This is common when applications were originally tuned for an older Java line. Review custom startup options and remove anything deprecated or rejected by the new runtime.
Class loading and module access issues
Applications that use reflection, internal JDK classes, or older libraries may fail because of stronger encapsulation. If your logs show access errors, update the affected libraries instead of relying on temporary workarounds where possible.
Encoding and locale differences
Text handling can change when default encoding, locale, or timezone assumptions are different. Test email content, CSV exports, file imports, and user-facing text. This is especially important if your application handles UK-specific formatting, dates, or currency values.
Certificate and TLS failures
Older integration endpoints may not support the security standards expected by newer Java releases. If an external service breaks after the runtime change, confirm whether the issue is caused by protocol mismatch, expired certificates, or outdated trust stores.
Recommended rollout approach for hosted Java applications
For a hosted Java or Tomcat application, the safest rollout is usually:
- Document the current version and settings.
- Test the new runtime in a staging or clone environment.
- Verify startup, logs, and core application functions.
- Check database, security, and file operations.
- Compare performance and restart behaviour.
- Schedule the change for a low-traffic period.
- Keep the previous runtime available for rollback.
If your platform provides several ready-to-install Java or Tomcat versions, use the simplest path that matches your application’s support matrix. If you upload a custom app server or private JVM configuration, test it carefully with the exact startup parameters you intend to use in production.
FAQ
Do I need to retest my whole application after every Java version change?
You should retest all critical user flows, integration points, and startup behaviour. If the version jump is small, the test scope may be shorter, but it should still include the main business functions, database access, and any external API calls.
Is it enough to confirm that Tomcat starts?
No. Tomcat starting only proves that the container launched successfully. It does not prove that your application, dependencies, database driver, TLS setup, or business logic work correctly under the new runtime.
Can I switch Java versions directly on production?
You can, but it is not recommended unless you have already tested the same runtime with the same application package in a separate environment. In managed hosting, a staged test is the safer and more practical option.
What if my application works on the new Java version but runs slower?
Review JVM memory settings, garbage collection behaviour, and application logs. A version change can alter performance characteristics even when functionality is intact. Test under realistic traffic before making the change permanent.
Should I also update Tomcat when changing Java?
Only if your current Tomcat version is not compatible with the new Java runtime or if the application requires newer servlet features. Do not change both at once unless you are prepared to troubleshoot both layers together.
What is the best practice in a Plesk-based Java hosting setup?
Use a separate test instance, verify the new Java version with the existing application, review logs, and only then move the change to the live service. If you use My App Server, keep the Tomcat or private JVM settings documented so rollback is straightforward.
Conclusion
Before switching runtime versions for a Java project, test compatibility at the framework, library, container, and infrastructure levels. In a hosting environment with Plesk and a managed Java setup such as My App Server, this means checking not only whether the application starts, but also whether it deploys cleanly, handles requests correctly, connects to the database, uses TLS safely, and restarts reliably.
A careful test process reduces downtime, helps you avoid hidden compatibility issues, and makes it much easier to move a Java application to a newer runtime with confidence. For hosted Tomcat, JSP, servlet, or private JVM deployments, the safest rule is simple: test first, switch second, and keep a rollback path ready.