Choosing the right Java runtime for a JSP project is mostly about matching the Java version to your application’s requirements, your servlet container, and the level of support you need from your hosting platform. In a managed hosting environment with Plesk and a dedicated Java service such as My App Server, this decision is usually simpler than in a self-managed server setup: you can run your own Tomcat instance, select a compatible JVM, and deploy JSP, servlet, and WAR applications without affecting other sites on the same hosting account.
The short answer is: use the newest Java runtime your JSP application and Tomcat version fully support, but do not upgrade blindly. JSP applications can depend on specific Java language levels, older libraries, or an application server version that only works with certain JDK releases. If you choose a runtime that is too new, the app may fail to start. If you choose one that is too old, you may miss security updates and compatibility with current frameworks.
What Java runtime means for a JSP project
For JSP hosting, the Java runtime is the environment that executes your application code. In practice, you are usually choosing a JDK or JRE version for the JVM behind Tomcat or another servlet container. JSP pages themselves are compiled into servlets at runtime, so the runtime version affects:
- Which Java language features your code can use.
- Which servlet container versions are supported.
- Whether third-party libraries load correctly.
- How securely and efficiently the application runs.
- Whether your deploy process works with your existing build output.
In a hosting control panel such as Plesk, the runtime choice is often tied to the service configuration for your private Tomcat or custom Java app server. With a platform like My App Server, this can be managed per account, which is useful when you want separation between applications or when a project must keep a specific Java version.
The best practice: follow application and container compatibility first
The most important rule is simple: the application and the container decide the minimum and maximum runtime requirements. Start by checking:
- The Java version declared in the project documentation or build file.
- The Tomcat version required by the application.
- The servlet and JSP specifications the app expects.
- Any framework or library constraints, such as Spring, Hibernate, or older JSP tag libraries.
- Whether the application was built for Java 8, Java 11, Java 17, or a newer release.
If a project was built years ago and never updated, it may still require Java 8. A newer project may be compiled for Java 17 or Java 21. In that case, the safest runtime is the one that matches the build target and is supported by the Tomcat version you use.
Recommended Java versions for JSP hosting
Java 8
Java 8 is still common in legacy JSP applications. Many older web apps, libraries, and enterprise-style frameworks were originally built against Java 8 and Tomcat 8 or early Tomcat 9 releases. If your application uses older dependencies or has not been maintained for a while, Java 8 may be the only stable choice.
Use Java 8 when:
- Your project documentation explicitly requires it.
- The application uses older JSP/Servlet libraries.
- You have legacy code that has not been tested with newer JDKs.
- Your deployment is tied to an older build pipeline.
Keep in mind that Java 8 is a compatibility choice, not the best default for new development.
Java 11
Java 11 is a strong baseline for many JSP and Tomcat projects. It is widely supported by application frameworks, works well for modern servlet containers, and offers a good balance between compatibility and current platform features. For many hosting environments, Java 11 is the safest default if the application does not require Java 8 specifically.
Use Java 11 when:
- The application is modern but not built for the newest runtime.
- You want a stable long-term runtime for a JSP project.
- Your Tomcat version supports Java 11.
- You want better security and maintenance than Java 8.
Java 17
Java 17 is a common choice for current applications and a very good option for new JSP hosting deployments. It is a long-term support release and is often recommended for newer servlet-based apps. Many recent versions of frameworks and application servers are tested with Java 17 by default.
Use Java 17 when:
- You are starting a new JSP project.
- Your code and dependencies support newer Java features.
- You want a modern LTS runtime with strong compatibility.
- Your Tomcat version is current enough to support it.
Java 21
Java 21 is another current LTS release and is a good option when your application stack has already been validated against it. For new projects, Java 21 may be the preferred runtime if your frameworks and servlet container are ready for it. However, it is more important to confirm compatibility than to choose the newest version by default.
Use Java 21 when:
- Your application is tested on Java 21.
- Your frameworks and libraries officially support it.
- You want to standardize on the latest LTS runtime.
How Tomcat version affects your Java choice
JSP applications run inside a servlet container such as Apache Tomcat. Tomcat version and Java version are closely connected. A runtime that works with one Tomcat release may not work with another. If you manage your own Tomcat in Plesk through My App Server, you should always verify the compatibility matrix before installing or switching runtime versions.
As a general rule:
- Older Tomcat versions often require older Java versions.
- Newer Tomcat versions are usually needed for Java 17 or Java 21.
- JSP and Servlet specification support changes with container versions.
- Vendor libraries may require a specific container/runtime combination.
If you are using a shared hosting account with a private JVM and a dedicated Tomcat instance, this compatibility check becomes even more important because you control the runtime directly. That flexibility is useful, but it also means the responsibility to choose the correct version is yours.
How to choose the right runtime for a JSP project
1. Check the application’s minimum Java version
Start with the source code or deployment documentation. Look for:
- Build tool settings in Maven or Gradle.
- Compiler target and source level.
- Framework release notes.
- Existing deployment notes from the developer or vendor.
- Any runtime warnings shown in logs.
If the application is compiled for Java 8 bytecode, it can usually run on a newer JVM, but only if the libraries and container are compatible. If the code uses newer Java language features, it will need a matching or newer runtime.
2. Confirm the Tomcat requirement
Before selecting the JVM, confirm which Tomcat version you will use. In My App Server, Tomcat can be installed and managed from the hosting control panel, which makes it easier to align the runtime with the project. Check whether your app uses:
- Classic JSP/Servlet behavior.
- Specific servlet API versions.
- Custom server settings or context configuration.
- Third-party Tomcat modules or connectors.
A runtime mismatch can cause deployment failures, class loading errors, or startup problems.
3. Review third-party libraries
Many JSP projects rely on libraries for database access, templating, validation, security, or file handling. Some older libraries are not compatible with newer Java releases. Others require a newer JVM to function properly. Always test the full stack, not only the application source code.
Pay special attention to:
- JDBC drivers.
- Legacy XML or SOAP libraries.
- Authentication and SSO integrations.
- Logging frameworks.
- Custom tag libraries or JSP plugins.
4. Choose the newest supported LTS version
If you have no legacy constraint, choose the newest long-term support release that your application and container fully support. In most cases, that means Java 17 or Java 21 for new deployments, or Java 11 if your stack is more conservative.
This approach usually gives you:
- Better security updates.
- Improved performance.
- More stable long-term maintenance.
- Better compatibility with modern tools.
5. Test before switching production
Even when the runtime looks compatible on paper, test it in a staging environment first. This is especially important for JSP applications that have been running for years. A runtime upgrade may reveal hidden issues in:
- Reflection-based code.
- Deprecated APIs.
- Character encoding behavior.
- Date and time handling.
- SSL or certificate-related libraries.
In a managed hosting platform, you can often create a separate service or test instance with the same Tomcat/JVM combination before changing the live deployment.
When to keep an older Java runtime
Older is not always worse. In hosting, the correct runtime is the one that keeps the application working reliably. Keep an older runtime when:
- The application was built and validated only on that version.
- A vendor only supports a specific Java release.
- The app depends on deprecated behavior that changed in newer JVMs.
- A migration would require code or dependency changes you are not ready to make.
That said, if you keep an older runtime, you should document the reason and plan a future upgrade. Older versions can increase maintenance overhead and may limit your ability to use newer libraries or container releases.
Using My App Server in Plesk to manage the runtime
With ITA’s My App Server extension, Java hosting is handled through Plesk in a practical way for JSP, servlet, and Tomcat-based projects. This is useful when you want a private JVM inside your hosting account instead of sharing one global server configuration with unrelated applications.
Typical advantages of this setup include:
- Dedicated Apache Tomcat instance for your app.
- Ability to choose from ready-made Java/Tomcat versions.
- Option to upload and configure other versions manually when needed.
- Service control from the hosting panel.
- Separate environment for WAR, JSP, and servlet deployments.
This makes it easier to align the runtime with your project, whether you are hosting a small internal tool, a customer portal, or a classic JSP website.
Common compatibility scenarios
Legacy JSP site built on Java 8
If an older JSP website runs on Java 8 and depends on libraries that have not been updated, the safest choice is usually to keep Java 8 and the corresponding Tomcat version until you can test an upgrade. Do not move directly to the newest runtime without checking application logs and dependency compatibility.
Modern web app using Spring and JSP
For a newer application with active maintenance, Java 17 is often the best default. It provides a modern LTS baseline and usually works well with current Tomcat releases. If the project has already been certified for Java 21, that may be the better choice.
WAR file from a third party
When you receive a prebuilt WAR file, use the vendor’s documented Java version first. If no documentation is available, start with the version most commonly supported by the framework or application server in use, then test carefully before going live.
Small internal JSP application
For a small app with limited traffic, the most important factor is stability. Choose a runtime that is easy to maintain and compatible with the build. In a managed hosting setup, this is often Java 11 or Java 17 unless the application requires something else.
Practical checklist before you deploy
- Confirm the Java version required by the project.
- Check the Tomcat version supported by that Java runtime.
- Review framework and library compatibility.
- Test the application on the target runtime in staging.
- Verify startup logs after deploy.
- Keep a rollback plan in case the new runtime breaks compatibility.
Signs that you picked the wrong runtime
If the runtime does not match the application, you may see issues such as:
- Tomcat fails to start.
- Class version errors.
- Missing method or class errors.
- JSP compilation failures.
- Library initialization problems.
- Unexpected behavior after deployment.
These problems usually point to a mismatch between the JVM, the container, and the application build target. In a Plesk-based Java hosting environment, check both the selected runtime version and the service configuration before assuming the app itself is broken.
FAQ
Which Java runtime is best for a new JSP project?
For new JSP projects, Java 17 is often the safest default. If your frameworks and Tomcat version support it, Java 21 is also a strong choice. Always confirm compatibility with your exact stack before deploying.
Can I run JSP on Java 8?
Yes, many older JSP applications still run on Java 8. It is best suited to legacy apps or projects that have not been updated for newer runtimes. For new development, a newer LTS release is usually better.
Does Tomcat version matter as much as Java version?
Yes. Tomcat and Java must be compatible with each other and with your application. A working Java version alone is not enough if the container release does not support it.
Should I always use the newest Java version available?
No. The newest version is only the right choice if your application, libraries, and Tomcat release have been tested with it. Compatibility is more important than novelty.
What is the safest choice if I am not sure?
If you are unsure, start with the Java version recommended by the application or framework documentation. If no guidance exists, Java 11 or Java 17 are common safe baselines for many JSP and Tomcat projects, but only after compatibility testing.
Can I change the runtime later in Plesk?
In a managed hosting setup with My App Server, you can usually adjust the runtime or install another Tomcat/Java version from the control panel. If you change it, test carefully because even a small version jump can affect library loading or JSP compilation.
Conclusion
The best Java runtime for a JSP project is the one that matches your application, container, and library requirements while staying as current as possible. For legacy applications, that may still mean Java 8. For most active projects, Java 11 or Java 17 is a better fit, and Java 21 is a strong option when the stack supports it. In a hosting environment with Plesk and My App Server, you have the practical advantage of managing your own Tomcat and private JVM, which makes it easier to select the correct runtime for each application and keep it isolated from other services.
When in doubt, check the build target, verify Tomcat compatibility, test in staging, and only then deploy to production. That approach reduces downtime and helps you keep your JSP hosting stable, secure, and easier to maintain.