Java Cloud Service: How to Run Java Applications in the Cloud

What is a Java cloud service?

A Java cloud service is a cloud platform that runs Java applications and manages some or all of the supporting layers for you, such as servers, the operating system, the Java runtime (JVM), the application server, scaling, and patching. You deploy your code or a packaged artifact; the service handles much of the rest.

The phrase is used in two ways, and it helps to separate them:

• The general category: any cloud service designed to host Java workloads, such as Azure App Service for Java, AWS Elastic Beanstalk with Java or Tomcat, Google Cloud Run running a Java container, or a managed Kubernetes cluster running Java microservices.
• A specific product: Oracle Java Cloud Service (often shortened to JCS), a platform Oracle offered for running applications on Oracle WebLogic Server. That product has been decommissioned, as explained below.

In cloud computing terms, most Java cloud services are Platform as a Service (PaaS) offerings, but Java also runs on raw virtual machines (IaaS), containers, and serverless functions. The service models section of our cloud guide explains how IaaS, PaaS, SaaS, and serverless divide responsibility between you and the provider.

What happened to Oracle Java Cloud Service?

Oracle Java Cloud Service has been decommissioned. According to Oracle's announcement, service on Oracle Cloud Infrastructure Classic ended on March 31, 2025, and service on Oracle Cloud Infrastructure (OCI) ended on May 31, 2025. Oracle's recommended replacement is Oracle WebLogic Server for OCI.

What Oracle JCS was

Oracle Java Cloud Service was a platform service for running Java EE applications on Oracle WebLogic Server in Oracle's cloud. It automated the creation of WebLogic domains and clusters, along with load balancing, backups, patching, and scaling, and it was commonly paired with Oracle Database Cloud Service. Many organizations used it to move existing on-premises WebLogic applications to the cloud without rewriting them.

The replacement: Oracle WebLogic Server for OCI

Oracle WebLogic Server for OCI is provisioned from the Oracle Cloud Marketplace and creates a WebLogic domain on OCI compute instances in a few steps. It is offered with usage-based licensing (Universal Credits) or bring-your-own-license (BYOL) terms for existing WebLogic customers, across Standard, Enterprise, and Suite editions. Compared with JCS, it gives administrators more direct control over the underlying infrastructure. Oracle also supports running WebLogic on Kubernetes through the open-source WebLogic Kubernetes Operator.

If you still depend on a JCS-era application

Because JCS itself is no longer running, the practical question is where a WebLogic application should live now. There are three common paths:

1. Stay on WebLogic in Oracle Cloud with WebLogic Server for OCI. This is the least disruptive option for applications that depend heavily on WebLogic features or Oracle Database.
2. Run WebLogic elsewhere, on virtual machines or Kubernetes in another cloud, under your existing Oracle licenses where the license terms allow it.
3. Move off WebLogic to another Jakarta EE server (such as JBoss EAP, WildFly, Open Liberty, or Payara) or refactor to a lighter framework such as Spring Boot or Quarkus. This takes more work but can reduce licensing costs and widen your platform choices.

Oracle's open-source WebLogic Deploy Tooling can export a domain's configuration and applications into a model that can be re-created on a new environment, which helps with the first two paths. The migration section below covers the general process.

How Java applications run in the cloud

Every Java application in the cloud runs on a Java Virtual Machine (JVM) provided by a JDK distribution. What changes between platforms is who manages the JVM, whether an application server is involved, and how the application is packaged: as a WAR or EAR file for an application server, as a self-contained JAR, as a container image, or as a function.

The JVM and JDK distributions

The JVM executes compiled Java bytecode. It comes from a JDK (Java Development Kit) or runtime distribution. Most cloud platforms use builds of OpenJDK, the open-source reference implementation. Common distributions include Eclipse Temurin (from the Adoptium project), Amazon Corretto, Microsoft Build of OpenJDK, Red Hat build of OpenJDK, Azul Zulu, and Oracle's own builds. They share the same core code but differ in support timelines and commercial terms.

Application servers vs. self-contained applications

Traditional enterprise Java applications are packaged as WAR or EAR files and deployed into a full application server, such as Oracle WebLogic Server, Red Hat JBoss EAP, IBM WebSphere Liberty, or Apache Tomcat (a lighter servlet container). The server provides services like transactions, connection pooling, messaging, and security.

Modern Java applications, especially those built with Spring Boot, Quarkus, Micronaut, or Helidon, usually embed a web server and are packaged as a single executable JAR. That self-contained style fits containers and PaaS platforms far more easily, which is why it dominates new cloud Java development.

Packaging for the cloud

• WAR or EAR file: deployed to an application server provided by the platform (for example, Tomcat or JBoss EAP on Azure App Service, or Tomcat on AWS Elastic Beanstalk).
• Executable JAR: run directly by a Java SE platform such as Elastic Beanstalk's Java SE environment or App Service's Java SE stack.
• Container image: the application plus a JDK in an OCI-compliant image, built with a Dockerfile or tools such as Jib or Cloud Native Buildpacks. Runs on any container service or Kubernetes.
• Function: a small handler deployed to a serverless platform such as AWS Lambda or Azure Functions.

Java inside containers

Modern JVMs detect container CPU and memory limits (container awareness arrived in JDK 10 and was backported to later Java 8 updates). One behavior surprises many teams: unless you set it, the JVM sizes its maximum heap at about a quarter of the memory available to the container. Teams commonly set -XX:MaxRAMPercentage to give the heap a larger share while leaving room for metaspace, thread stacks, and native memory. Getting this wrong leads either to wasted memory or to containers being killed for exceeding their limit.

Types of Java cloud services

Java applications can run on five main types of cloud service: virtual machines (IaaS), Java platform services (PaaS), managed container services, Kubernetes, and serverless functions. A sixth category, managed application server offerings, serves applications that depend on WebLogic or JBoss EAP.

Scroll the table sideways to see all columns.

Virtual machines

Running Java on cloud virtual machines means installing and maintaining the JDK and any application server yourself. It is the most flexible option and the simplest way to move an existing application without changes, but it leaves patching, scaling, and availability with your team. Our guide to how cloud servers work covers the fundamentals.

Java platform services (PaaS)

Platform services accept a JAR, WAR, or source code and run it on a managed Java stack. Azure App Service supports Java SE, Tomcat, and JBoss EAP. AWS Elastic Beanstalk offers Java SE and Tomcat platforms based on Amazon Corretto. Google App Engine runs Java in its standard and flexible environments. These services handle load balancing, scaling rules, runtime patching, and deployment slots, and they suit teams that want minimal infrastructure work.

Managed container services

Managed container services run a container image and handle scaling, including scaling to zero on some platforms, without requiring you to operate a Kubernetes cluster. Google Cloud Run and Azure Container Apps are popular choices for Spring Boot services; Amazon ECS with AWS Fargate offers a similar serverless container model on AWS. Because the application is a standard container, it is easier to move between providers.

Kubernetes

Kubernetes suits organizations running many Java services that need consistent deployment, networking, and observability across teams. Managed options include Amazon EKS, Azure Kubernetes Service, Google Kubernetes Engine, Oracle Container Engine for Kubernetes (OKE), and Red Hat OpenShift (available on premises and as managed services on major clouds). Kubernetes adds operational complexity, so it pays off at a certain scale rather than for a single application.

Serverless functions

Serverless platforms run Java code in response to events and bill only for execution time. The traditional drawback for Java is cold-start latency, because the JVM and framework take time to initialize. AWS Lambda SnapStart addresses this for Java by restoring functions from a cached snapshot of an initialized execution environment. GraalVM native images, covered below, are another approach. Serverless Java works well for event processing, scheduled jobs, and APIs with irregular traffic.

Managed application servers

Some applications depend on application server features such as EJBs, JMS, distributed transactions, or vendor-specific APIs. For these, platforms that provide the server itself avoid a rewrite: Oracle WebLogic Server for OCI for WebLogic applications, and JBoss EAP on Azure App Service or on Red Hat OpenShift for JBoss applications. IBM also offers WebSphere Liberty for containerized deployments.

Java cloud service options by provider

All major cloud providers support Java well, but each has different strengths. AWS offers the broadest set of options and its own JDK (Amazon Corretto). Microsoft Azure has close ties to Spring and Red Hat JBoss EAP. Google Cloud is strong on containers with Cloud Run and GKE. Oracle Cloud is the natural home for WebLogic and Oracle Database workloads.

Scroll the table sideways to see all columns.

Service names, supported Java versions, and features change regularly. Confirm current support in each provider's documentation before planning a migration.

Java frameworks and runtimes for the cloud

The framework an application uses shapes which Java cloud service fits it best. Spring Boot is the most widely used choice for cloud Java. Jakarta EE is the standard for enterprise application servers. Quarkus, Micronaut, and Helidon are designed for fast startup and low memory use in containers and serverless platforms.

The javax to jakarta change

Starting with Jakarta EE 9, the enterprise Java APIs moved from the javax.* package namespace to jakarta.*. Spring Boot 3 and current application servers use the new namespace. Older applications must be updated before they can run on modern platforms, which is often the largest single task when modernizing a legacy Java application. Automated tools such as OpenRewrite can handle much of the mechanical change.

Features that matter in the cloud

Virtual threads, final since Java 21, let applications handle large numbers of concurrent requests without large thread pools, which can reduce the resources an I/O-heavy service needs. Checkpoint and restore approaches, such as the OpenJDK CRaC project and AWS Lambda SnapStart, cut startup time by resuming from a snapshot of a warmed-up application.

Java versions and JDK licensing in the cloud

Choose a Java cloud service that supports a current long-term support (LTS) release of Java, and understand the license terms of the JDK it uses. Most cloud platforms run no-cost OpenJDK distributions, while Oracle JDK has its own commercial terms.

Scroll the table sideways to see all columns.

Non-LTS releases (such as Java 26 in March 2026 and Java 27 in September 2026) arrive every six months and are supported only briefly, so most production cloud workloads stay on LTS versions. Oracle has said it plans the next LTS, Java 29, for September 2027. Support end dates differ by vendor: Amazon, Microsoft, Red Hat, Azul, and the Adoptium project each publish their own timelines.

JDK licensing

OpenJDK builds from Adoptium, Amazon, Microsoft, Red Hat, and others are free to use in production, with paid support available from several vendors. Oracle JDK's license terms have changed several times, and commercial use of some Oracle JDK versions requires a Java SE subscription, which Oracle has priced per employee since 2023. Because licensing depends on the exact version, distribution, and use, confirm which JDK your cloud platform or container images use and review the current terms, particularly after migrations or audits.

Performance and cost considerations for Java in the cloud

Java cloud costs are driven mostly by memory, because the JVM reserves heap and other memory up front, and by how many instances must stay running to avoid slow startups. Tuning JVM memory settings, picking the right framework, and matching the platform to traffic patterns usually matter more than the choice of provider.

• Size memory deliberately. Set heap as a percentage of container memory, leave headroom for non-heap memory, and measure actual usage before resizing.
• Pick a suitable garbage collector. G1 is the default and suits most services. ZGC offers very low pause times for latency-sensitive applications at some memory cost. Small containers may be better served by other settings, so test with realistic load.
• Plan for startup time. Where platforms scale to zero or run functions, slow JVM startup affects users. Options include keeping a minimum number of instances warm, SnapStart, CRaC, class data sharing, or native images.
• Match platform to traffic. Steady traffic fits PaaS or Kubernetes with committed capacity; spiky or low traffic fits container services that scale to zero or serverless functions.
• Consider processor architecture. Java runs well on Arm-based instances, which several providers offer at a lower price per unit of performance for many workloads. Test your application and dependencies first.
• Count licensing. WebLogic, JBoss EAP, and Oracle JDK subscriptions can outweigh infrastructure costs. Include them in comparisons.

For the broader picture of what drives cloud bills, see the cloud server cost section of our main guide.

Security and operations for Java cloud applications

Securing a Java cloud application means keeping the JDK and every third-party library patched, protecting secrets and access, and monitoring the application closely. Managed Java cloud services patch the runtime for you, but your application's dependencies remain your responsibility.

Dependencies and patching

Most Java applications include dozens or hundreds of open-source libraries. The Log4Shell vulnerability in Apache Log4j (CVE-2021-44228), disclosed in December 2021, showed how a flaw in one widely used library can expose huge numbers of applications at once. Use dependency scanning in your build pipeline, keep a software bill of materials (SBOM), and update base container images and JDK patch releases on a regular schedule. On IaaS, patching the JDK is also your job; on PaaS, the platform usually updates the runtime within a version you select.

Secrets and access

Store database passwords and API keys in a secrets manager (such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or OCI Vault) rather than in property files or container images. Use workload identities or managed identities so applications receive short-lived credentials instead of stored keys. The cloud server security section of our main guide covers the wider controls.

Observability

The OpenTelemetry Java agent can collect traces, metrics, and logs from most Java applications without code changes and send them to the monitoring tool of your choice. Health endpoints (for example, Spring Boot Actuator or MicroProfile Health) let platforms restart unhealthy instances, and JDK Flight Recorder provides low-overhead profiling when you need to investigate performance problems in production.

How to choose a Java cloud service

Choose a Java cloud service by starting with the application: how it is packaged, which application server features it depends on, which Java version it needs, and what its traffic looks like. Then weigh your team's skills, your existing cloud provider, licensing, and the platform's long-term roadmap.

Scroll the table sideways to see all columns.

Evaluation checklist

• Java version support: the platform supports your current version and the next LTS you plan to adopt.
• Server compatibility: the application server or framework you rely on is supported, or you have a plan to move off it.
• Startup and scaling: scaling behavior and cold starts fit your traffic and latency needs.
• Data proximity: the platform runs in the same region and network as your database to keep latency low.
• Operations: logging, monitoring, deployment slots or rollbacks, and CI/CD integration work the way your team does.
• Security and compliance: network isolation, managed identities, secrets integration, and the certifications your industry requires.
• Lifecycle: the service is actively developed, not in a retirement period like Oracle JCS or Azure Spring Apps.
• Total cost: infrastructure, licensing, support, and the staff time needed to run it.

Migrating Java applications to a cloud service

Migrating a Java application to the cloud follows the same stages as any cloud migration (assess, plan, migrate, test, cut over, optimize), with extra attention to application server dependencies, the Java version and namespace, session state, local file storage, and configuration.

Java-specific assessment questions

• Which Java version and framework versions does the application use, and does it still use javax.* packages?
• Which application server features does it rely on (JNDI lookups, EJBs, JMS queues, XA transactions, server-specific APIs)?
• Does it keep user sessions in server memory? Cloud platforms scale horizontally, so sessions usually need to move to a shared store such as Redis or a database.
• Does it write to the local file system? Files should move to object storage or a shared file service.
• Where do configuration and secrets live, and can they be supplied through environment variables or a secrets manager?
• What does it connect to (databases, mainframes, message brokers, internal services), and how will those connections work from the cloud?

Migration approaches

1. RehostMove the application and its server to cloud virtual machines unchanged. Fastest, with the fewest cloud benefits.
2. ReplatformMove to a managed platform with minimal code changes, such as a WAR to Tomcat on a PaaS, or WebLogic to WebLogic Server for OCI.
3. ContainerizePackage the application and runtime as a container image and run it on a container service or Kubernetes.
4. RefactorUpdate the codebase, for example moving from a full application server to Spring Boot or Quarkus, splitting out services, or adopting managed databases and messaging.

Useful tools

Tools that help with Java migrations include Oracle's WebLogic Deploy Tooling for moving WebLogic domains, OpenRewrite for automated code upgrades (such as Java version updates and the javax to jakarta change), Red Hat's Migration Toolkit for Applications for analyzing applications before a move, and the providers' own migration guides. For the general process, including cutover and post-migration monitoring, see the cloud migration section of our main guide.

Getting outside help with Java in the cloud

Organizations without in-house Java cloud experience often bring in specialists for assessments, WebLogic or JBoss migrations, containerization, and JVM performance tuning. The same evaluation principles apply as for any cloud services provider.

Relevant providers include cloud consultancies with Java practices, cloud application development services teams that build and modernize Java applications, and managed service providers that operate Java platforms after migration. When evaluating them, ask for examples of Java migrations similar to yours, how they handle application server dependencies and licensing, and how they will transfer knowledge to your team. Our guide to cloud tech services covers provider types, pricing models, contracts, and a full selection checklist.

Java cloud service FAQs

Related guides