Microsoft returns to Java with Azure-focused OpenJDK release

A couple of weeks ago an anonymous Twitter account told the story of an almost-forgotten Microsoft April Fool’s prank, the 1996 seeding of empty boxes of a “Microsoft Coffee” Java development tool across Seattle. Of course, at the time, the pranksters didn’t know that Microsoft was already working on its own Java implementation, Visual J++.

That was the start of the first part of Microsoft’s Java story, which ended up the subject of litigation between Microsoft and Sun Microsystems over its support for nonstandard Windows APIs, before being removed from the Visual Studio suite of tools. That might have been the end of the story, if not for Azure and Microsoft’s commitment to “go where the developers are.”

Part two of the story has been Java’s return to Microsoft’s platform, with Java tools for Visual Studio Code and support for Java on Azure. And now Microsoft is offering its own open source Java distribution, named Microsoft Build of OpenJDK, more than a decade after Visual J++’s demise.

Microsoft, Java, and the Azure cloud

So why Java now? It’s all about keeping the costs for Azure-hosted applications to a minimum. Java’s convoluted history has led to it being owned by Oracle, which commercially licenses Java development tools and runtimes. If you don’t want to pay for a commercial license, there’s an alternative, in the shape of the GPL 2-licensed OpenJDK. Following the public Java SE (Standard Edition) specification, OpenJDK provides source and binaries for Java runtimes and the developer toolkit, with contributions from many different companies and individuals, including Microsoft.

Supporting Java on the Azure cloud has brought Microsoft back to Java, hence Microsoft recently announced its own build of OpenJDK 11, targeted at developers working with Java on Azure. Using an open source Java avoids complex licensing issues with some Java implementations. Since Microsoft offers Java support for Azure App Service, Azure Functions, and Azure Spring Cloud (among others), using OpenJDK will keep their costs to a minimum as Microsoft won’t need to pass licensing costs on to users as part of Azure subscriptions.

Now available for download, Microsoft’s preview build of OpenJDK 11 is for Linux x64, MacOS x64, and Windows x64, with debug symbols for all the releases along with source for your own builds. If you want to work with Arm64, there’s an early access build of OpenJDK 16 for Windows on Arm, so you can start to experiment with it. They all will work with Visual Studio Code’s Java development tools or with any other OpenJDK-ready Java development environment, simplifying setting up and running a test environment on your PC.

A build of OpenJDK 11 is already available in the Azure Cloud Shell, so you can use it with jshell to try out code snippets. Being able to run Java code from the command line, either in the Windows Terminal or in the Azure Portal, will help you ensure your code will run on the new JVM, giving you more confidence about the upcoming transition.

Initial support for OpenJDK 11 makes sense, even if it is based on the 2018 release. Microsoft has been using Azul’s Zulu Enterprise implementation of OpenJDK 11 on Azure for some time now, as it’s a long-term support release. Switching to its own OpenJDK 11 from the equivalent Zulu release will have much less impact on existing code than a jump later in 2021 to the next long-term support release, OpenJDK 17. Microsoft describes its OpenJDK tooling as a drop-in replacement for any other OpenJDK release, on your own system or on Azure.

It’s important to note that Microsoft Build of OpenJDK is a Microsoft-specific build of OpenJDK. That means it contains Azure-specific and Microsoft-specific fixes that may not yet be fully available in the upstream distribution. However, this is not Microsoft forking OpenJDK, as all the fixes it’s including in its distribution have been submitted to the OpenJDK project. What it’s shipping today is a version that already has Azure and Windows support and bug fixes tested and running, so your code won’t be affected by known problems. Other releases will eventually ship with the same fixes, just not as quickly as Microsoft’s.

Using OpenJDK on Azure

Microsoft will be making Microsoft Build of OpenJDK the default JVM for Azure managed services by the end of 2021, so it’s a good time to download the preview and start checking that your code will run on it. It’s built using the same scripts as Eclipse’s Adoptium QA tools, and it’s been tested against the Java Technology Compatibility Kit, so Microsoft’s OpenJDK should be a drop-in replacement for the existing Azul Zulu OpenJDK implementation. However, it’s always a good idea to be sure that it won’t affect your code.

If you’re bringing your own Java to an Azure virtual machine image, there won’t be any changes as your existing image will continue to run under your management as always. If you want to change JVM you’ll need to rebuild your image to use the Microsoft OpenJDK tools.

Microsoft isn’t only focusing on long-term support releases; it’s working on an Arm build of Java 16, based on OpenJDK 16. Arm support has been one of Microsoft’s biggest contributions to OpenJDK to date, providing a basis for OpenJDK’s Apple Silicon support as well as for Microsoft’s own SQ1 and SQ2 Arm processors. Behind the scenes, Microsoft is working on Arm silicon for Azure, with a focus on edge and content distribution. An internal Arm build of the OpenJDK platform will help it deliver edge runtimes for Azure services like Spring Cloud and for consumer-facing services like those that run Microsoft’s many thousands of Minecraft servers.

Although Java SE provides a common foundation for Java applications, it’s not the full Java Enterprise Edition release (now known as Jakarta EE). Microsoft has yet to make any announcements about support for Jakarta EE on its platforms, and much of its Azure Jakarta documentation focuses on working with tools such as Red Hat’s JBoss Enterprise Application Platform. It will be interesting to see if Microsoft makes any moves in this direction or if it will continue with its existing Red Hat partnership.

Returning to its own Java builds makes a lot of sense for Microsoft. Java remains popular, and cloud migrations of existing on-premises enterprise applications need a cloud Java. Using OpenJDK helps keep costs to a minimum while still adhering to the Java specification, ensuring existing code continues to run. Microsoft knows the capabilities of its virtual machines and its own Linux container OS and can produce an optimized OpenJDK build and deliver its changes upstream. Any other organization building on OpenJDK can take advantage of them—a win for everyone in the Java community who wants to use Java in the cloud and on the edge.