Container Best Practices – Using OpenJDK Images

Container Best Practices – Using OpenJDK Images

Containerizing Java is now a common practice. However, doing it wrong with Oracle’s JDK can become very expensive. Using the wrong base Java image might slip by initially, but it can create huge compliance risks down the line.

This guide explains why OpenJDK should be your default choice for Java containers—and how to keep those images secure and compliant.

We’ll cover the licensing pitfalls of Oracle JDK in containers, best practices for building OpenJDK images, and steps to replace Oracle JDK across your pipeline. The goal: containerize Java the right way —fully compliant, secure, and cost-free.

Pro Tip: “The smallest Docker image can cause the biggest audit.”

Read our ultimate guide for more insights, Oracle Java in Cloud & Container Environments.

The Compliance Risk of Oracle Java in Containers

Using Oracle’s JDK inside a container still requires a valid license. Many teams mistakenly assume that Java in a container is “free” or that Oracle’s no-fee terms cover it.

In reality, Oracle’s no-fee development license does not extend to most production uses – especially not to images you share or deploy widely. The moment you package Oracle Java into a container and use it beyond personal experimentation, you risk violating the license.

Oracle’s licensing is strict about redistribution. If you publish or host a container image with Oracle JDK (for example, on a registry for others to pull), you’re effectively redistributing Oracle’s software. Oracle’s no-cost terms explicitly exclude commercial redistribution.

Even internally, if multiple teams pull Oracle-based images from a private registry, it can count as a licensable deployment. In Oracle’s eyes, every instance running Oracle Java needs to be paid for (often under a costly per-employee subscription model).

This means a single Docker image using Oracle JDK can potentially trigger a license requirement for your entire company. It’s a recipe for an audit disaster.

Simply put, containerizing Oracle JDK doesn’t hide your usage—it creates an audit trail. Oracle has become aggressive in auditing Java usage. They can track downloads from their registry and aren’t shy about pursuing compliance fees.

If your containers include Oracle’s Java, you’re leaving evidence that could lead to a surprise audit and an even more surprising bill.

Pro Tip: “Every image you ship is a potential audit trail.”

Why Use OpenJDK Base Images

OpenJDK base images are a haven for Java in containers. They are fully open-source, freely available, and 100% compatible with Oracle JDK.

In practice, modern Java applications run identically on OpenJDK builds—no code changes needed. By choosing OpenJDK images, you remove the licensing landmines without sacrificing any Java features or performance.

Using OpenJDK eliminates Oracle’s fees and risks. Oracle’s licensing can charge per employee (a model that gets expensive fast), but OpenJDK has no such strings attached.

There are no usage fees, and you don’t need to worry about an audit. OpenJDK is distributed under a GPL-compatible license, allowing free commercial use and redistribution. This means you can base your Docker images on OpenJDK and share them internally or publicly with confidence.

Equally important, OpenJDK is well-supported by the community and multiple vendors. Whether you get your Java from Eclipse Temurin, AdoptOpenJDK (now Adoptium), Azul Zulu, Amazon Corretto, or Red Hat’s builds, it’s all OpenJDK under the hood.

These distributions provide timely updates and long-term support at no cost. In short, OpenJDK gives you the same Java without the worry of an unexpected compliance issue.

Read how Java is licensed on OCI, Java Licensing on Oracle Cloud (OCI).

Comparison Table – Oracle Java vs OpenJDK in Containers

Let’s compare how Oracle JDK and OpenJDK differ when used in container images:

Oracle’s container images come with strings attached, while OpenJDK images are hassle-free. The bottom line: if you’re containerizing Java, sticking with OpenJDK keeps you in the clear on licensing and costs.

Pro Tip: “A free build is useless if it’s not legally redistributable.”

Building Secure OpenJDK Images

Once you’ve chosen OpenJDK, you should also follow best practices to build secure and lean images:

• Use official or certified images: Always start with trusted OpenJDK base images. For example, use the official Eclipse Temurin images on Docker Hub or vendor-provided OpenJDK images. Avoid random Java images from unknown sources. Official images are more likely to be up to date and free of malware.
• Pin your image versions: Don’t use a floating latest tag for your Java base image. Pin to a specific version (e.g. openjdk:17.0.8-jdk) so you know exactly what you’re running. This prevents unexpected updates from sneaking in and breaking your build. When you’re ready to update, do it in a controlled manner by choosing a new version tag.
• Keep images minimal: Slim down your Java containers to reduce the attack surface. Use the smallest base image that meets your needs – for example, a JRE-only image if you don’t need the full JDK, or an Alpine-based OpenJDK image if compatible. Include only necessary libraries and remove any fluff. Fewer packages mean fewer vulnerabilities and smaller, faster-deploying images.
• Automate vulnerability scanning: Integrate security scans into your CI/CD pipeline to catch outdated or risky components. Use container scanning tools to flag known CVEs in your images (including OS packages and the JDK itself). This way, if an OpenJDK version or an OS layer has a new vulnerability, you’ll know and can respond quickly.
• Rebuild regularly for patches: Treat your base image like a living component that needs updates. Plan to rebuild Java images on a regular schedule (for example, monthly or whenever a new Java security patch is released). Regular rebuilds ensure you pull in the latest OpenJDK security fixes and any OS package updates. Don’t allow your Java runtime to go stale.

Following these practices keeps your OpenJDK containers secure over time. You’re trading the old license maintenance for a new kind of maintenance: keeping images patched and lean. The payoff is a secure, compliant container environment.

Pro Tip: “Security patches are your new license terms.”

AWS vs Oracle? – AWS’s Amazon Corretto vs Oracle Java in AWS.

Migrating from Oracle to OpenJDK Containers

Already have containers using Oracle JDK? Switching them to OpenJDK is usually straightforward and well worth the effort.

Here’s how to migrate your Java containers off Oracle:

1️⃣ Identify all container images using Oracle JDK. First, find where Oracle Java is in use. Scan your Dockerfiles and container images for any Oracle JDK base image or Oracle Java installation. This discovery step is crucial—you can’t fix what you haven’t found.

2️⃣ Replace base image references with OpenJDK (Temurin) equivalents. Once you’ve pinpointed the Oracle-based images, edit those Dockerfiles. Swap out FROM oraclejdk... or Oracle Linux with JDK for an OpenJDK alternative (e.g., FROM eclipse-temurin:17-jre or openjdk:11-jdk-slim). There is an OpenJDK drop-in for virtually every Oracle image. Choose a comparable OpenJDK version and distribution.

3️⃣ Test your applications in staging for compatibility. Build the new images and run your Java applications in a non-prod environment. In most cases, you won’t notice any difference – the apps should run as usual on OpenJDK. Still, run your test suites and verify performance just to be safe. This step gives confidence that the switch doesn’t break anything.

4️⃣ Update CI/CD pipelines to block Oracle JDK images. Adjust your build process and policies so this doesn’t happen again. For example, remove any credentials or URLs that allow pulling Oracle’s images. Implement checks in CI that prevent using disallowed base images (you can maintain a whitelist of approved base images, all of which should be OpenJDK). The idea is to make it impossible for Oracle JDK to creep back in.

5️⃣ Rebuild and redeploy everything on OpenJDK. With testing complete and pipelines adjusted, rebuild your Java containers using the new OpenJDK base images. Push these clean images out to your registry and deploy them to replace the old ones. In the future, your container fleet will be Oracle-free. You’ve now closed that compliance gap.

Migration might sound daunting, but for most teams, this process takes hours or days, not weeks. You’ll immediately remove Oracle from your software stack, cutting off their audit visibility into your containers. The result: your Java deployments run on open source Java with zero licensing headaches.

Checklist – Container Compliance & Maintenance

Use this checklist to keep your Java container environment compliant and well-maintained:

✅ Only use OpenJDK-based base images. (Ban Oracle JDK from all container builds.)
✅ Verify image sources are trusted and updated. (Official builds, kept up-to-date.)
✅ Replace any Oracle JDK in internal registries. (Purge old non-compliant images.)
✅ Automate image scanning and rebuilds. (Continuously monitor for vulnerabilities.)
✅ Enforce a “no Oracle JDK” policy in Dockerfiles. (Make it a firm organizational rule.)

5 Pro Tips

1️⃣ Treat base image approval as a compliance step. Have your compliance or architecture team vet and approve base images, just like they would for any licensed software.
2️⃣ Use minimal images (e.g., Alpine) to shrink risk. Smaller images mean fewer packages and fewer vulnerabilities. An Alpine or distroless Java image can significantly reduce potential exposure.
3️⃣ Build once, deploy many — consistency matters. Standardize on a single OpenJDK image per Java version and use it everywhere. By building an image once and reusing it, you avoid drift and ensure that every environment runs the same approved Java build.
4️⃣ Maintain an internal registry of approved OpenJDK builds. Curate your own library of Java-based images that are patched and compliant. Make it easy for developers to pull from your trusted images rather than grabbing random ones from the internet.
5️⃣ Automate Java version upgrades via CI/CD. When a new Java update or LTS release comes out, have your pipeline detect it, run tests, and roll out the updated image. This keeps you on a secure, supported Java without manual effort.

5 Actions to Take After Reading

1️⃣ Audit your container registry for Oracle JDK images. Identify any images in your repositories that include Oracle’s Java and flag them for replacement.
2️⃣ Replace all Oracle-based images with approved OpenJDK bases. Start a project to systematically swap out those base images and rebuild your containers.
3️⃣ Update build policies to block Oracle registries. Prevent developers or CI jobs from pulling Oracle JDK images (for example, by restricting credentials or using allow-lists for base image sources).
4️⃣ Document OpenJDK usage for compliance proof. Keep a record that all your Java instances are OpenJDK. This documentation can be a lifesaver in a compliance audit – it shows you’ve standardized on a free Java.
5️⃣ Review all CI/CD pipelines to enforce this change. Double-check that your CI pipelines, Dockerfile linting, and image scanners are configured to detect and reject any Oracle JDK usage going forward.

By following these steps, you’ll containerize Java in a way that is secure, cost-free, and audit-proof.

Adopting OpenJDK images and best practices not only avoids Oracle’s Java traps, but also gives your DevOps teams a simpler, worry-free path for running Java in the cloud.

Enjoy the peace of mind that comes with doing Java the right way in containers – with no license strings attached.

Read about our Java Advisory Services.

Do you want to know more about our Java Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit