# Dragonwell 11: Alibaba's OpenJDK build for running Java at scale on Linux > Alibaba Dragonwell is a downstream OpenJDK build tuned for the e-commerce, financial and logistics services Alibaba runs on more than 100,000 servers, published in standard and extended variants, and it is a Linux x86_64 only distribution today. **dragonwell-project/dragonwell11** — Alibaba Dragonwell11 JDK - Repository: https://github.com/dragonwell-project/dragonwell11 - Website: https://www.aliyun.com/product/dragonwell - Stars: 585 · Forks: 118 - Language: Java - License: GPL-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/dragonwell-project-dragonwell11 ## A downstream OpenJDK with a scale story behind it The introduction is unusually direct about where this comes from. Over the years, Java has proliferated in Alibaba, many applications are written in Java, and many of the Java developers there have written more than one billion lines of Java code. Alibaba Dragonwell, as a downstream version of OpenJDK, is the OpenJDK implementation at Alibaba optimized for online e-commerce, financial and logistics applications running on 100,000+ servers. The README calls it the engine that runs these distributed Java applications in extreme scaling. That framing explains the two obvious questions. Why a fork at all, and who is it for. The answer to the first is that a deployment of that size gives the operator a specific vantage point on what the JVM actually does, and a fork is how you act on that. The answer to the second is operators running Java at scale on Linux. The licensing posture is stated as being clearly a friendly fork under the same licensing terms as the upstream OpenJDK project, with Alibaba committed to collaborate closely with the OpenJDK community and intending to bring as many customized features as possible from Dragonwell to upstream. The repository carries a LICENSE file, an ADDITIONAL_LICENSE_INFO file and an ASSEMBLY_EXCEPTION file, and the Makefile header carries the Oracle copyright with the GNU General Public License version 2 terms and the Classpath exception. The primary language is Java, the default branch is master, and the homepage is the Alibaba Dragonwell product page. ## Linux x86_64 is the whole platform story The usage section contains one sentence that should decide the question for most people: Alibaba Dragonwell JDK currently supports Linux/x86_64 platform only. One platform, one architecture. There is no Windows build, no macOS build, no ARM build in this repository. There is a separate dragonwell8 repository, and the wiki image reference in the README points at the dragonwell8 images path, which suggests the family is split by major version rather than by platform. This is a deployment constraint rather than a philosophical position, and it makes sense given the origin: the workloads described run on Linux servers in Alibaba's own infrastructure. But it means Dragonwell is not a general-purpose JDK replacement for a team with mixed infrastructure. If your application also runs on a developer laptop, a Windows build pipeline or an ARM edge device, you now have two JDKs to maintain, and the differences between them are exactly the kind that surface as subtle behaviour differences rather than compile errors. The version line is JDK 11 as well, so this branch is not tracking the current feature release of Java. The release tags confirm it, with names like dragonwell-standard-11.0.32.28_jdk-11.0.32-ga and dragonwell-extended-11.0.32.29_jdk-11.0.32-ga, where the JDK patch level 11.0.32 matches the OpenJDK 11 update it is built from. So the decision is narrower than it first looks. You are choosing a specific downstream of a specific, now older, feature release, for one operating system and one architecture. ## Standard and extended, and the version numbers in the tags The recent releases list shows two product lines, and the naming convention is the only place the distinction is spelled out. The standard line appears as dragonwell-standard-11.0.32.28_jdk-11.0.32-ga, tagged Alibaba_Dragonwell_Standard_11.0.32.28.9, released on 2026-09-20. The extended line appears as dragonwell-extended-11.0.32.29_jdk-11.0.32-ga, tagged Alibaba_Dragonwell_Extended_11.0.32.29.9, released on 2026-09-22. An earlier extended build, dragonwell-extended-11.0.31.28_jdk-11.0.31-ga, is dated 2026-05-20. The two variants moved independently within two days of each other, which tells you they are released on separate cadences rather than as a single stream. Note also that the standard and extended builds at the same JDK level carry different Dragonwell patch numbers, 11.0.32.28 against 11.0.32.29, so the two lines are not lockstep in their own versioning either. The README does not spell out what the extended variant adds. That is a real gap for anyone evaluating the choice, and the honest thing to do is read the release notes and the documentation directory rather than infer it from the names. What can be said from the repository is that the two variants are tracked and published separately, and that the extended line is the one whose builds arrive with their own numbering. The distribution artifact naming is also worth noting, because the string is long and it encodes the variant, the Dragonwell patch level, the JDK level and the build tag. Scripts that fetch a specific build will need to match that whole string, not a short tag. ## Installing and pointing your applications at it The installation instructions are short because a JDK is a tarball. You may download a pre-built Alibaba Dragonwell JDK from the GitHub releases page at https://github.com/dragonwell-project/dragonwell11/releases, and then uncompress the package to the installation directory. To enable it for your application, you set JAVA_HOME to point to the installation directory. The README also covers the YUM package route, following the instructions prompted from the post-install outputs, and it shows the form that takes. ```bash ======================================================================= # Assuming Alibaba Dragonwell 11 is installed to: # /opt/alibaba/java-11-alibaba-dragonwell # You can set Alibaba Dragonwell as default JDK by exporting following environment variables: $ export JAVA_HOME=/opt/alibaba/java-11-alibaba-dragonwell $ export PATH=${JAVA_HOME}/bin:$PATH ======================================================================= ``` The two exports are the entire activation story, and that is the point of a JDK distribution as opposed to a framework. There is no agent to install, no sidecar to run, no configuration file to write. You point JAVA_HOME at the directory and the JVM in that directory is the one that runs your application. The practical implication for a deployment pipeline is that a container image needs a different base layer or an extra layer that replaces the JDK, and a fleet needs the environment variable set consistently across every service. The README's own framing, applications running on 100,000+ servers, is a reminder that the operational cost of a JDK change at that scale is a fleet-wide change, not a per-service one. One more detail in the repository root is worth knowing about. There is a version.txt file, a make.sh script and a make/ directory, alongside the usual OpenJDK build machinery, which tells you the source tree is a full JDK build tree and can be compiled rather than only downloaded. ## What the published work reveals about the fork's direction The publications section is more informative than it looks, because it names the technical areas Alibaba has been working in and publishing about. The 2021 paper is Towards a Serverless Java Runtime, presented in the ASE 2021 Industry Showcase. A serverless runtime is a change to how the JVM starts and stays warm, which is a different kind of work from tuning a garbage collector. The 2020 paper is Platinum: A CPU-Efficient Concurrent Garbage Collector for Tail-Reduction of Interactive Services, at USENIX ATC. The phrase in the title, tail reduction, is the key: a garbage collector designed around the long tail of request latency rather than around average throughput. For an e-commerce front end, the p99 matters more than the mean, and a collector designed for that goal is a visible difference from a stock one. The 2019 paper is SafeCheck: Safety Enhancement of Java Unsafe API, at ICSE. That one is about making the Unsafe API safer, which is a hardening change rather than a performance change, and it is the kind of work that gets upstreamed. And the two 2018 papers, Cloud-Scale Java Profiling at Alibaba and Java Performance Troubleshooting and Optimization at Alibaba, are about the tooling and practice that a large Java estate requires. Read together, the trajectory is coherent: profiling at scale, then a latency-oriented collector, then hardening Unsafe, then a serverless runtime. That is a fork iterating on JVM-level concerns in response to what running Java at Alibaba's scale actually exposed, and it is also consistent with the stated intent to bring customised features upstream. The homepage is the Alibaba Dragonwell product page, and the repository is not archived, with the last push on 2026-09-22. ## Where Dragonwell is the wrong choice Three boundaries are worth stating plainly, and none of them are quirks of this particular build. The first is the platform and version line. Linux x86_64 only, on JDK 11. A team that needs a current JDK feature release, an ARM server, a macOS developer machine or a Windows build agent cannot use this as a drop-in, and the JDK 11 constraint means the long-term upgrade path eventually runs out. The second is the question of what you actually get from a downstream. The tuning that Dragonwell adds is described in general terms in the README and detailed in the papers, but the operational reality of a fork is that you now track a build whose changes are documented partly in academic papers and partly in release notes rather than in a single upstream changelog. When something behaves differently from stock OpenJDK, the debugging path is longer. For a deployment at the scale described, that cost is absorbed by a team with Java runtime expertise; for a smaller team, it may not be. The third is the maintenance obligation. The release names are long, and the naming convention means automated fetches have to match a full string rather than a short tag. The build tags here show a standard build in September 2026 and an extended build two days later, and an extended build from May 2026, so the two lines move on different schedules. The realistic alternative is the stock OpenJDK 11 build with the same patch level, which removes the fork question entirely but also removes the tuning. The other alternative is to stay on a current OpenJDK release and solve the latency and scaling problems in the application and the runtime configuration instead of in the VM. For most teams that is the better trade, and Dragonwell earns its place in the specific case where the workload shape matches the one it was tuned for. ## Conclusion Adopt Dragonwell 11 if you run Java workloads on Linux x86_64 at a scale where the vendor's own tuning is worth having and you are prepared to take an OpenJDK downstream rather than a stock build. Do not adopt it if you need Windows, macOS, ARM or a current JDK feature release, since this branch is JDK 11 on Linux x86_64 only. Before you deploy, check the variant you need, standard or extended, and note the last push was on 2026-09-22 with a standard release on 2026-09-20. ## FAQ ### What is Alibaba Dragonwell and who is it for? Dragonwell is a downstream version of OpenJDK built at Alibaba and optimized for online e-commerce, financial and logistics applications running on 100,000+ servers. It is intended for operators running Java at that scale on Linux, and it is positioned as a friendly fork under the same licensing terms as upstream OpenJDK. ### Which platforms does Dragonwell 11 support? Alibaba Dragonwell JDK currently supports the Linux/x86_64 platform only. There is no Windows, macOS or ARM build in this repository, and the branch is built on JDK 11. ### How do I install Dragonwell and make my applications use it? Download a pre-built JDK from the GitHub releases page, uncompress the package to the installation directory, and set JAVA_HOME to that directory, adding ${JAVA_HOME}/bin to PATH. If you installed via YUM, follow the instructions in the post-install output. ### What is the difference between the standard and extended Dragonwell builds? The repository tracks them as separate release lines with separate build numbers, for example dragonwell-standard-11.0.32.28_jdk-11.0.32-ga and dragonwell-extended-11.0.32.29_jdk-11.0.32-ga. The README does not spell out what the extended variant adds, so the release notes and documentation are the places to check. ### What technical work has Dragonwell published? The publications list includes Towards a Serverless Java Runtime at ASE 2021, Platinum, a CPU-efficient concurrent garbage collector for tail reduction of interactive services at USENIX ATC 2020, SafeCheck, a safety enhancement of the Java Unsafe API at ICSE 2019, and two 2018 papers on cloud-scale Java profiling and performance troubleshooting at Alibaba. ## Sources - [dragonwell-project/dragonwell11 on GitHub](https://github.com/dragonwell-project/dragonwell11) - [License: GPL-2.0](https://github.com/dragonwell-project/dragonwell11/blob/master/LICENSE) - [Project website](https://www.aliyun.com/product/dragonwell) - [README](https://github.com/dragonwell-project/dragonwell11/blob/master/README.md) - [Releases](https://github.com/dragonwell-project/dragonwell11/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dragonwell-project-dragonwell11