Eclipse Temurin is the community OpenJDK distribution from the Adoptium project under the Eclipse Foundation. The distribution is binary compatible with the Oracle Java SE distribution at the major version level. The distribution is freely available and is used in production by many enterprises that have migrated away from the Oracle Java SE Universal Subscription. The Adoptium project also operates a Technology Compatibility Kit programme that validates the Temurin binaries against the Java specification. The Temurin distribution is therefore the principal community alternative to the Oracle Java distribution. This article describes the migration plan, the validation steps, and the support model.
The Temurin distribution.
Eclipse Temurin is published by the Adoptium project on the adoptium.net website. The distribution covers the principal Java long term support versions and is released on the same cadence as the upstream OpenJDK project. The distribution is available for Linux, Windows, and macOS on x86 and on Arm processor architectures. The platform coverage matches the coverage of the Oracle Java SE distribution.
The Temurin distribution is published under the GPL with the classpath exception. The licence permits free use in commercial and non commercial environments without a per use commercial fee. The licence does not include warranties or commercial support obligations. The community support is provided through the Adoptium project channels and through the broader Java community.
The migration plan.
The migration plan from Oracle Java to Eclipse Temurin has four phases. The discovery phase identifies the Oracle Java installations in the environment and the Java versions in use. The validation phase tests the application portfolio against the Temurin distribution at the target version. The deployment phase rolls out the Temurin distribution to the production environment in a controlled sequence. The decommissioning phase removes the Oracle Java installations and the supporting commercial agreements.
The four phases should be planned at the start rather than executed in sequence. The discovery and the validation can run in parallel for different parts of the application portfolio. The deployment can begin on validated applications while the validation continues on the remaining applications. The decommissioning should occur only after all applications have completed the deployment phase.
The discovery step.
The discovery step identifies every Oracle Java installation in the environment. The discovery covers the desktop estate, the server estate, the container estate, and the application installer footprints. The discovery should produce a record for each installation that includes the location, the version, the patch level, and the application that depends on the installation.
The discovery tools available include the standard inventory tools in the buyer environment, the Oracle audit script if available, and third party tools that target Java specifically. The output of the discovery should be normalised into a single canonical record format. The record forms the input to the validation step and the rollout plan. See the compliance posture note for the broader record keeping framework.
The validation step.
The validation step tests the application portfolio against the Temurin distribution. The test plan should cover the functional behaviour, the performance behaviour, and the operational behaviour of the application under the Temurin runtime. The test plan should be completed in a non production environment that mirrors the production configuration.
The validation should pay particular attention to applications that depend on Oracle specific features. The Oracle specific features include some monitoring options in older Java versions, the Java Flight Recorder in commercial only configurations, and some packaged tools that are not part of the OpenJDK reference. Applications that depend on these features may require alternative implementations on the Temurin distribution.
The deployment step.
The deployment step rolls out the Temurin distribution to the production environment. The rollout should follow a controlled sequence that begins with low risk applications and progresses to mission critical applications as confidence grows. The rollout should also include a defined rollback procedure that returns the application to the Oracle Java runtime if a production issue arises.
The deployment should also address the desktop estate where Java is used for development tools or for legacy desktop applications. The desktop deployment is typically more numerous than the server deployment and may require automation through the standard endpoint management tools. The desktop deployment is also typically lower risk because the desktop Java workloads are less performance sensitive.
The support model.
The Temurin distribution does not include commercial vendor support. The support model needs to be addressed at the start of the migration through one of three options. The first option is community support through the Adoptium project channels. The community support is sufficient for many buyers and is the default option for non critical workloads. The second option is third party commercial support from vendors such as Azul Systems, BellSoft, or IBM. The third party support provides a documented support path at a fraction of the Oracle subscription cost. The third option is internal support where the buyer maintains internal expertise on the Java runtime and resolves issues without external escalation.
The selection of the support model should be driven by the criticality of the Java workloads and by the internal capability. A buyer with mission critical Java workloads and limited internal expertise should select third party commercial support. A buyer with non critical workloads and strong internal expertise can rely on community support. See the broader OpenJDK migration note for the comparison across distributions.
Engaging an independent advisor.
The Temurin migration benefits from external review on the planning and the commercial dimensions. An independent advisor can build the migration plan, validate the target version selection, and negotiate the third party support agreement if required. The independent review also produces a defensible business case for the migration decision and supports the internal conversation with the stakeholders.
For the wider cluster see Java Licensing. For the service see Contract Review. For the deal structure see Java SE Universal. For the Oracle product see Oracle Java. For the full research read the Oracle Java Negotiation Guide.
A worked example.
A North American retail buyer migrated from Oracle Java 8 to Eclipse Temurin 21 in 2024. The buyer had approximately four hundred and fifty server installations of Oracle Java and approximately eight thousand desktop installations. The migration was planned over six months and executed over a further six months.
The validation step identified twelve server applications that depended on the Java Flight Recorder in the commercial configuration. The applications were migrated to the open Java Flight Recorder in OpenJDK 21 with no behavioural change. The deployment step proceeded through low risk applications in the first quarter and through mission critical applications in the second quarter. The desktop deployment was automated through the endpoint management tools and completed in approximately six weeks. The buyer eliminated the Oracle Java SE Universal Subscription at the next renewal and avoided approximately eight hundred thousand dollars per year in subscription cost.