Oracle Java SE vs Microsoft Build of OpenJDK is the Java distribution decision where Oracle's Employee Metric is the audit exposure, Microsoft's free OpenJDK build is the Azure-aligned alternative backed by Microsoft Premier Support, and the buyer-side path is a clean migration that closes the Oracle commercial relationship while keeping the Azure operating model intact.

What Oracle Java SE and Microsoft Build are

Oracle Java SE Universal Subscription. Oracle's commercial Java SE distribution under the Employee Metric model since January 2023. Universal Subscription includes Oracle JDK binaries, Java Management Service (JMS), GraalVM Enterprise Edition, and Oracle's commercial Java support. The Employee Metric counts every employee plus full-time contractors, consultants, and temporary workers — regardless of Java consumption.

Microsoft Build of OpenJDK. Microsoft's free, production-ready, TCK-certified OpenJDK distribution, released in 2021 and consolidated from earlier Microsoft Java investments. Microsoft Build supports Java 11, 17, 21, 23, and onward LTS releases (Microsoft chose not to backport to Java 8 — for Java 8 workloads Microsoft directs customers to Eclipse Temurin or Amazon Corretto, or to upgrade to Java 11+ which is the recommended path). Microsoft Build ships for Linux (x86_64, AArch64), macOS (Intel, AArch64), Windows (x86_64, AArch64), and as Docker images. Microsoft Build is the default Java on Azure App Service for Java, Azure Spring Apps, Azure Functions for Java, and is recommended for Azure Kubernetes Service Java workloads.

Microsoft is one of the largest contributors to OpenJDK upstream. Microsoft engineers maintain OpenJDK ports for Windows AArch64 (ARM64), contribute garbage collector improvements, JIT optimisations, and security patches. Microsoft runs Java workloads at internal scale — LinkedIn, parts of Microsoft 365, Yammer, Bing, parts of Azure — which underwrites the production-grade claim for enterprise customers.

The two products are binary-compatible at the same JDK major version (Java 11+). Code compiled against Oracle JDK 17 runs unmodified on Microsoft Build 17. The JVM behaviour, garbage collectors, JIT compilers, standard library APIs, and tooling are functionally identical because both descend from the same OpenJDK upstream.

Licensing models compared

Oracle Java SE Universal Subscription pricing (per employee per month, tiered).

Microsoft Build of OpenJDK licensing. GPL v2 with Classpath Exception. Commercial use in production is permitted at no cost, including in enterprise applications, including in shipped commercial products. No Microsoft licence purchase required — Microsoft Build is published as a public good, similar to .NET. Microsoft Premier Support and Microsoft Unified Support coverage of Microsoft Build is included at no incremental cost for existing support contract customers; the support coverage requirement is the existing Microsoft Support contract, not a separate Java licence.

For Azure-hosted Java workloads (Azure App Service for Java, Azure Spring Apps, Azure Functions for Java, Azure Kubernetes Service with Microsoft Build), Microsoft Build is the supported default Java distribution. Azure Standard or Professional Direct Support Plans provide support coverage for these services including the Microsoft Build runtime, at no additional Java-specific cost.

Azure integration — where Microsoft Build wins

The operational case for Microsoft Build is its native fit with Azure Java services. For Azure-heavy estates, this matters operationally:

• Azure App Service for Java. Microsoft Build is the default Java runtime. The Azure portal, ARM templates, Bicep, Terraform azurerm provider, and Azure CLI all reference Microsoft Build versions natively (Microsoft-OpenJDK-11, Microsoft-OpenJDK-17, Microsoft-OpenJDK-21). Switching to a non-Microsoft JDK on App Service requires a custom Docker container.
• Azure Spring Apps. Spring Boot Java runtime on Azure. Microsoft Build is the default and Microsoft's Spring Apps team specifically tunes and tests the Spring framework against Microsoft Build.
• Azure Functions for Java. Serverless Java functions. Microsoft Build 11, 17, 21 are the supported runtimes; Oracle JDK is not a supported runtime on Azure Functions.
• Azure Kubernetes Service (AKS). Microsoft Build is the recommended OpenJDK distribution for Java workloads on AKS, with Microsoft Premier Support coverage for Azure-hosted Microsoft Build.
• GitHub Actions setup-java. Microsoft Build is one of three default distributions (alongside Temurin and Corretto) in the actions/setup-java GitHub Action. Switching to Microsoft Build in CI/CD pipelines is a single config-line change.
• Visual Studio Code Java extensions. Microsoft's Java extensions for VS Code default to Microsoft Build. Developer tooling alignment is integrated.
• Azure DevOps Pipelines. Microsoft Build is pre-installed on Microsoft-hosted Azure Pipelines agents.

For organisations with significant Azure investment — Azure ARC, Azure Sentinel, Microsoft 365 E5, Azure AD / Entra ID, Microsoft Defender for Cloud, Azure Monitor — Microsoft Build of OpenJDK extends the existing Microsoft commercial relationship to cover Java with no additional licence cost. The single-vendor support story for Java + .NET + cloud + identity + security is operationally cleaner than splitting Java support across Oracle while the rest of the stack runs Microsoft.

For non-Azure Java estates, Microsoft Build is still a perfectly fine OpenJDK distribution — but the operational advantages narrow. On AWS, Corretto's native fit is closer. On vendor-neutral or multi-cloud estates, Eclipse Temurin's neutrality is more appealing.

Support model and patch cadence

Microsoft Build of OpenJDK patch cadence. Microsoft Build releases security patches and bug fixes on the OpenJDK upstream quarterly cadence — typically within 7 to 14 days of upstream release. Microsoft's Java engineering team contributes to the upstream patches and ensures Microsoft Build incorporates them promptly.

Microsoft's published LTS commitment windows are somewhat shorter than Oracle's extended-support windows. Microsoft commits to a defined LTS window aligned to OpenJDK upstream; Oracle commits to longer extended-support windows for paying Universal Subscription customers (e.g., Java 8 through 2030). The practical impact: customers running Microsoft Build on Java 8 should plan an upgrade to Java 11 or 17 within the support window. For Java 11, 17, 21, and beyond, Microsoft's support windows align with normal LTS planning cycles for most enterprises.

For Azure-hosted workloads, Microsoft includes 24/7 support coverage for Microsoft Build through the Azure Support Plan (Standard or Professional Direct). For off-Azure Java workloads, Microsoft Premier Support or Microsoft Unified Support contracts cover Microsoft Build alongside the rest of the Microsoft stack — no separate Java-specific support purchase is required.

Compatibility and performance

Compatibility. Microsoft Build of OpenJDK is binary-compatible with Oracle JDK at the same major version (Java 11+). Java applications, JAR files, WAR files, Spring Boot apps, application server deployments, and JVM tuning parameters that work on Oracle JDK 17 work on Microsoft Build 17 without code or configuration changes. Microsoft Build passes the Technology Compatibility Kit (TCK) for Java SE — TCK certification is independently verified by Microsoft.

Performance. Microsoft Build uses the HotSpot JVM with the standard OpenJDK JIT compilers (C1, C2) and garbage collectors (Serial, Parallel, G1, ZGC, Shenandoah). Microsoft's specific contributions to OpenJDK include Windows AArch64 (ARM64) port optimisations, G1 GC improvements, security hardening, and FFI improvements. Performance benchmarks (SPECjbb, SPECjvm, real-world workloads) show Microsoft Build within ±2 percent of Oracle JDK and Temurin across most scenarios.

Microsoft has invested specifically in two areas where Microsoft Build offers operational advantages: (a) Windows AArch64 ARM64 support — the Microsoft Build is the most polished ARM64 Windows Java distribution for Apple Silicon developer machines running Windows-on-ARM and for Azure ARM-based VMs (Cobalt, Azure Compute Manager); (b) Azure-tuned defaults — Microsoft Build on Azure App Service for Java is tuned by the Azure team for typical container and Spring Boot configurations.

Tooling compatibility. JConsole, VisualVM, Java Mission Control, Java Flight Recorder, jcmd, jstat, jmap, jstack all work on Microsoft Build identically to Oracle JDK. Build tools (Maven, Gradle, Ant), CI/CD platforms (Azure DevOps, GitHub Actions, Jenkins), application servers (Tomcat, Jetty, WildFly, Spring Boot), and APM tools (Application Insights with Java agent, Datadog, New Relic, Dynatrace) support Microsoft Build without modification.

Migration path on Azure

The technical migration from Oracle JDK to Microsoft Build of OpenJDK is straightforward, particularly on Azure where Microsoft Build is the default. For each affected system:

1. Inventory. Identify all systems running Oracle JDK. Use Java Management Service (JMS) telemetry if deployed, or Azure Resource Graph queries for Java application services. Forensic inventory is the audit-defence prerequisite.
2. Version match. For each Oracle JDK installation at Java 11 or above, install matching Microsoft Build version. Java 11 → Microsoft Build 11, Java 17 → Microsoft Build 17, Java 21 → Microsoft Build 21. For Java 8 workloads, evaluate upgrade to Java 11+ — Microsoft does not ship Java 8 (Microsoft directs Java 8 users to Temurin or Corretto, or to upgrade Java versions which is recommended in 2026 for security and feature alignment).
3. Install on VMs. Microsoft publishes installers as DEB, RPM, MSI, PKG, tar.gz, and Docker images (mcr.microsoft.com/openjdk/jdk). The installer registers JAVA_HOME, PATH, and update-alternatives.
4. Update Azure App Service / Spring Apps configuration. Switch the Java runtime version to Microsoft-OpenJDK-11 (or 17, 21). Single configuration change via Azure portal, CLI, or ARM/Bicep template.
5. Update GitHub Actions / Azure DevOps Pipelines. Switch setup-java distribution to microsoft. Single line change in pipeline YAML.
6. Update Dockerfiles. Replace FROM eclipse-temurin:17 or FROM openjdk:17 with FROM mcr.microsoft.com/openjdk/jdk:17-ubuntu. Single line change.
7. Verify. Run application smoke tests on Microsoft Build. JVM behaviour is identical so functional verification is typically 1 to 4 hours per application.
8. Decommission Oracle. Uninstall Oracle JDK with timestamped log entry. This is the audit-defence evidence.
9. Exit Universal Subscription. Notify Oracle of non-renewal at the contractual notice window. Get written confirmation from Oracle's contract management.

For Azure-heavy estates, a typical migration completes in 3 to 6 weeks — somewhat faster than on-premise or AWS estates because the Azure platform changes are configuration-only rather than infrastructure-level.

Worked savings: 12,000-employee Azure-heavy enterprise

Scenario: A 12,000-employee enterprise has been using Oracle JDK across approximately 320 Java applications, with 65 percent of those workloads running on Azure (Azure App Service for Java, Azure Spring Apps, AKS-hosted Spring Boot microservices, Azure Functions for Java). Universal Subscription proposal lands at $8.25 PEPM × 12,000 × 12 = $1,188,000 per year.

For this profile, the 3-year savings from the Microsoft Build migration land at $3.4M. The Azure-aligned migration is faster and cheaper than the average OpenJDK migration because (a) Azure platform changes are configuration-only for App Service, Spring Apps, and Functions, (b) the existing Microsoft Premier Support contract covers Microsoft Build off-Azure at no incremental cost, (c) the existing Azure Support Plan covers Microsoft Build on-Azure at no incremental cost.

The Java 8 holdout subset (typically 5 to 15 percent of Java estates in 2026) is the operational complication for Microsoft Build because Microsoft does not ship Java 8. Three options for the Java 8 subset: (a) upgrade to Java 11 or 17 — the recommended path given Java 8's end-of-public-update status; (b) run Temurin or Corretto for Java 8 with no commercial support; (c) procure Azul Zulu Enterprise commercial support for Java 8 regulated workloads (typically $80k to $200k over 3 years depending on JVM count).

Decision framework

Choose Microsoft Build of OpenJDK when:

• The Java estate is concentrated on Azure (Azure App Service for Java, Azure Spring Apps, Azure Functions for Java, AKS-hosted Java workloads).
• The organisation has Microsoft Premier Support, Microsoft Unified Support, or Azure Support Plans that already cover the existing Microsoft stack. Microsoft Build coverage is included at no incremental cost.
• The Java estate is at Java 11 or higher — Microsoft Build does not ship Java 8.
• The development workflow is Microsoft-centric (Visual Studio Code, GitHub Actions, Azure DevOps Pipelines) where Microsoft Build is the pre-installed default.
• The cross-stack support relationship is valued — Java + .NET + Azure + Microsoft Entra ID + Microsoft 365 all under a single Microsoft Support contract.

Choose another OpenJDK when:

• For AWS-aligned estates → Amazon Corretto's native fit on Amazon Linux and AWS Support Plans is closer.
• For Java 8 workloads → Eclipse Temurin, Amazon Corretto, or Azul Zulu (Microsoft Build does not support Java 8).
• For vendor-neutral preference → Eclipse Temurin's multi-sponsor Adoptium governance is more appealing.
• For deepest commercial Java support relationship → Azul Zulu Enterprise has the longest history and broadest enterprise references.
• For Red Hat Enterprise Linux estates with bundled support → the Red Hat build of OpenJDK comparison covers the RHEL/OpenShift-aligned migration path in full.
• For estates with JavaFX desktop applications or GraalVM Enterprise native image workloads → the BellSoft Liberica comparison covers the full-stack OpenJDK path including Liberica Full (JavaFX) and Liberica NIK (ahead-of-time native compilation).

The buyer-side reality: for Azure-heavy estates, Microsoft Build is the default vendor answer. Microsoft has cultivated the Azure Java story specifically to offer Azure customers a no-cost Oracle Java SE alternative that does not require a third-party OpenJDK relationship. For most enterprise Azure customers, Microsoft Build is the right answer — the operational advantages are real and the support relationship is already in place. For non-Azure platforms, the right answer is platform-aligned: Red Hat OpenJDK for RHEL/OpenShift, BellSoft Liberica for JavaFX or Spring Boot-heavy estates, and the model is the same: drop the Employee Metric, exit the Universal Subscription, defend the audit that follows. Bring the modelled ROI to the Java migration ROI calculator to size the buyer-side opportunity.

Buyer-side negotiation moves

1. Forensic Java inventory across the Azure estate. Use Azure Resource Graph queries to enumerate all Azure App Service for Java sites, Azure Spring Apps deployments, Azure Functions Java runtime resources, and AKS Java workloads. Use JMS or OS-level inventory for VMs running Oracle JDK. Forensic inventory is the audit-defence baseline.
2. Migrate Azure-hosted Java to Microsoft Build first. The Azure platform changes are configuration-only and complete fastest. Closing the Oracle JDK consumption on the Azure footprint is the quickest win.
3. Migrate on-premise and off-Azure Java in waves. For VM-hosted Java on-premise or on AWS/GCP, Microsoft Build is still a valid choice — but the migration is similar in complexity to Temurin or Corretto. Plan in waves.
4. Confirm Microsoft Premier / Unified Support covers Microsoft Build off-Azure. Engage Microsoft's account team to formally extend the existing Microsoft Support contract to include Microsoft Build coverage. Written confirmation matters.
5. For Java 8 holdouts — choose Temurin / Corretto, or upgrade Java versions. Microsoft Build does not ship Java 8. The strategic answer is to upgrade Java versions where possible; the tactical answer is to run Temurin or Corretto for Java 8 with commercial support from Azul or BellSoft for regulated workloads.
6. Document the migration evidence. Timestamped logs of Oracle JDK removal, Microsoft Build installation, Universal Subscription contractual exit. Documentation is the buyer-side insurance against Oracle re-engagement.
7. Cap the Universal Subscription renewal at 3 percent if you choose to retain a subset. Some customers retain Universal Subscription for a small regulated subset and migrate the rest. In that scenario, cap the residual subscription's renewal and ensure the Employee Metric is calibrated to the actual scope, not the full headcount.

FAQ — Oracle Java SE vs Microsoft Build of OpenJDK

What is Microsoft Build of OpenJDK?

Microsoft Build of OpenJDK is Microsoft's no-cost, production-ready, TCK-certified distribution of OpenJDK. Released in 2021 as part of Microsoft's strategic Java investment, Microsoft Build supports Java 11, 17, 21, 23, and onward LTS releases. The distribution is binary-compatible with Oracle JDK and other OpenJDK builds, ships for Linux (x86_64, AArch64), macOS (Intel, ARM), Windows (x86_64, AArch64), and is available as Docker images and Azure App Service runtime. Microsoft Build is the default Java for Azure App Service for Java and Azure Spring Apps. Microsoft commits to LTS support windows aligned to OpenJDK upstream releases.

Is Microsoft Build of OpenJDK free for commercial use?

Yes. Microsoft Build of OpenJDK is licensed under GPL v2 with Classpath Exception — the standard OpenJDK licence — and is free for commercial production use, including in enterprise applications, including in shipped commercial products. Microsoft Premier Support and Microsoft Unified Support cover Microsoft Build of OpenJDK for Azure customers and existing Microsoft Support contract customers at no incremental cost. There is no separate Java licence, no Oracle Master Agreement, no Employee Metric, no audit exposure.

How does Microsoft support Microsoft Build of OpenJDK?

Microsoft Build of OpenJDK is supported under Microsoft's standard Azure Support Plans (Developer, Standard, Professional Direct) and through Microsoft Premier Support / Unified Support contracts. For Azure-hosted Java workloads (Azure App Service for Java, Azure Spring Apps, Azure Kubernetes Service, Azure Functions for Java, Azure Web Apps), Microsoft Build is the supported default. Microsoft engineers contribute to OpenJDK upstream and operate Java workloads at scale internally (LinkedIn, Bing, Yammer, parts of Microsoft 365), which underwrites the production-grade claim. Microsoft commits LTS support windows aligned to the OpenJDK upstream EA/LTS schedule.

Should we choose Microsoft Build of OpenJDK over Eclipse Temurin or Amazon Corretto?

Choose Microsoft Build for Azure-aligned estates where the Java workloads run on Azure App Service, Azure Spring Apps, AKS, or Azure VMs — Microsoft Build is the default Java on those Azure services and Microsoft Premier Support is the natural support relationship. Choose Amazon Corretto for AWS-aligned estates. Choose Eclipse Temurin for vendor-neutral or multi-cloud estates. All three are technically equivalent OpenJDK distributions; the choice is about operational fit and support-relationship alignment. All three eliminate the Oracle Employee Metric — the commercial outcome is the same regardless of which OpenJDK replaces Oracle Java SE.

Does Microsoft Build support Java 8?

No. Microsoft Build of OpenJDK is shipped for Java 11, 17, 21, 23 and onward LTS releases. Microsoft chose not to backport Microsoft Build to Java 8, in part because Java 8's mainstream public update period ended in 2019 and continuing to ship Java 8 in 2026 would conflict with the strategic encouragement to upgrade to modern LTS versions. For Java 8 workloads, the choices are: (a) upgrade the application to Java 11 or 17 — the recommended path; (b) use Eclipse Temurin 8 (community-supported quarterly patches through May 2026); (c) use Amazon Corretto 8 (Amazon-supported through May 2026 with quarterly patches); (d) procure commercial Java 8 support from Azul Zulu Enterprise (paid support through 2030+) or BellSoft Liberica.

Can Microsoft Build of OpenJDK be deployed in regulated industries?

Yes. Microsoft Build is deployed in production across financial services, healthcare, regulated retailers, telecoms, and public sector organisations. For Azure-hosted workloads, Microsoft Build inherits the Azure compliance certifications (SOC 2, ISO 27001, HIPAA, FedRAMP High, IRAP, GDPR, and others). For off-Azure workloads requiring vendor-backed indemnification, Microsoft Premier Support coverage of Microsoft Build provides commercial support backing. The combination of Microsoft Build runtime plus Microsoft Premier Support satisfies the regulatory requirements for vendor-backed Java support without the Oracle Employee Metric. For broader context on Oracle Java commercial mechanics and the audit-defence playbook, see our piece on Oracle Java Licensing Guide and our comparison with Oracle Java SE vs Eclipse Temurin.

Independence statement: Oracle Licensing Experts is an independent buyer-side advisory firm. Not affiliated with Oracle Corporation. We have no commercial relationship with Microsoft. All numbers above reflect published list pricing for Oracle Java SE Universal Subscription and benchmark migration economics as observed in buyer-side engagements.

Related guides