Microsoft deploys over 500,000 Java Virtual Machines (JVMs) internally – excluding all Azure services and customer workloads – with needs that go from back-end microservices to Big Data systems, message brokers, event streaming services, and gaming servers. More than 140,000 of these JVMs are already based on the Microsoft Build of OpenJDK.
Linked In (owned by MS) is a big user of JVM. Kafka originated at Linked In. [1] Similarly many other acquired companies by MS may be using JVM. Also many BigData related OSS systems require JVM. Most likely MS must be running a few of those too.
Why not? They probably have a bunch running for QA and similar. Maybe even a handful for fun. But I agree that this number is probably insignificant. I would guess in the low 10s of servers.
there are plenty of vendors providing builds of OpenJDK. I am not sure how are they different from one another and what distinguishing features they could provide. Wishing for a comparison matrix!
I don't know about other vendors but as far as I can tell, Microsoft is the only vendor providing an aarch64 build of OpenJDK for Windows thus making it available to all those cute Windows on ARM machines.
> I do not know why microsoft dupplicates this effort.
Why do you say they are duplicating efforts?
The builds on the RedHat page are for: x86 (32-bit), x64 (64-bit x86) but any mention of aarch64, which is what Microsoft has been working on with Azul Systems, is conspicuously missing.
(aarch64 or ARM64 is the 64-bit extension of the ARM architecture.)
Isn't this on the roadmap in some form? I thought I read they were consolidating the WinRT interop with the Xamarin Android apis for a consistent interop style.
They work on language translation concepts. C++ to winrt, C# to WinRT, Rust to WinRT,... And also C# to (Android) Java or C# to (iOS) Swift/Objective-C.
But that is just interop/language translation beyond stone age C ABI like most languages do.
>Please do send us your comments, thoughts, and ideas to help us improve this. Visit our GitHub page (Some link here: https://github.com/microsoft/openjdk/discussions) to send us your feedback.
I have heard that switching from a JDK vendor to another can alter runtime performance.
It is to be expected as the JVM is a C++ codebase, its performance depends on the compiler flags.
Hence I wonder if there is a vendor that has found the optimal configuration e.g
-03 + x86-v3 (AVX) + LTO + PGO (e.g autofdo) + BOLT
TLDR: This can happen, but is not done much in practice.
Most vendors use pretty similar build toolchains in order to maintain platform support baselines. Typically any improvements get made at OpenJDK and then filter back down to downstream distributions.
One of the things we're looking to do is to add Metadata to the release to make the exact toolchain transparent going forward.
No. Most likely Azure customers are asking for a supported JDK from Microsoft since MS customers tend to be very uh... insular.
There's never been any question about the JDK/JVM license. There are tons of different ones that are all compiled from OpenJDK sources and offered for free (Amazon Correto, Azul Zulu) or licensed out with commercial support (Azul Zing).
Just because there are others that have gotten away with having their own JDK & not faced Oracles lawyers doesn't mean they weren't one day going to have to litigate it out.
The precedent matters.
I'm again willing to accept coincidence here, but doubt will be eternal.
> Microsoft Build of OpenJDK 11 binaries may contain backported fixes and enhancements we deem important to our customers and our internal users. Some of these may have not yet been formally backported upstream and are clearly signposted in our release notes. This allows us to expedite improvements and fixes much faster while we proceed to upstream those changes in parallel. Updates will be free and available to every Java developer to deploy anywhere.
Hey Karianna, to my surprise I actually am able to run JetBrains IDEs using the pre-release JDK 16 for Windows on ARM. I had to add "--illegal-access=warn" to idea.bat + I had to delete runnerw64.exe. I've tested with IntelliJ 2021.1.
We saw some folks running Minecraft Java Edition on Windows on ARM with our JDK 16 EA builds. So... technically, it is possible. It will mostly depend on JetBrains' IDEA
This is a good thing. Even though my shop has mostly moved on from Java (to Python and other things), we still run plenty of software that depends on it.
I wonder how badly Oracle's attempt to monetize Java is going.
This page is confusing because it lists multiple versions of OpenJDK, that not all of them are built by the same "vendor/entity".
The OpenJDK binaries 9+ available at jdk.java.net are built by Oracle and some versions are not really "pure" because Oracle deliberately chose to exclude Shenandoah GC (Red Hat) from their binaries hosted on this site. [1]
Meanwhile, the binaries available on the Linux systems listed in this page (versions 8 and older) are all built by the Linux distributions teams, and not by Oracle.
Pure OpenJDK builds are those that are created from the source code and with all the features enabled (including all the GCs available), and ideally built from a single vendor/entity.
If you want "pure OpenJDK builds", your best bet is AdoptOpenJDK (now known as Eclipse Adoptium). [2]
Is this a new try of "Embrace, extend, and extinguish" [1]?
Now that OpenJDK is GPL-ed, they can add anything they want! And of course - they will not try to put the changes upstream, because this is not "extend" anymore...
So happy to see Java have broad support from various vendors. I've always been a fan despite it's shortcomings. I'm wary of using "captive" corporate languages like Go, C#, Kotlin. And there aren't any other options with the combination of speed and ease of use for high level work
That support has always been there since around 2000.
Sun, Oracle, BEA, IBM, Excelsior, PTC, Aonix, Aicas, Fujitsu, HP, Nokia, Sony, Azul and to certain extent Apple (for a while it was the Swift of OS X), Microsoft (until J++ venture turned into C#)
I want to believe it's a good thing, but having to support a platform that doesn't support good ole symlinks is incredibly aggravating. Npm too would be much easier to work with if it could have had symlinks. If only there weren't some weird platform-I-don't-want-anyways's limitations gumming thing up. Microsoft extending their Microsoftisms into every software platform is a frustrating limitation to keep facing.
I'm fine with the general attitude of harmony and oh yay, a bigger tent for everyone, it doesn't bother me, and platform flexibility has it's upsides. But there really is a downside to this all too, and it goes unremarked. I want to at least put down some words, somewhere, to remark that Windows support is constraining & limiting. OpenJDK of course is cross platform & already supports Windows, but the sign that this is a proper & well supported thing in Windows will quite likely amplify Windows user's expectations that all the libraries & tools they run across are going to be catered to them & their experience. It increases a library maintainer's burden, supporting this new class of usually-not-that-expert users. I encourage us to reflect on this as a mini Eternal September event, of Microsoft extending the reach of their community into something that used to be a little more deliberate; that's maybe putting it a little strongly, but I think we can recognize the parallel.
To summarize, are more prevalent technical constraints, and re-emphasized demands upon open-source Java authors, in this shift to further allow & encourage Windows based Java development.
56 comments
[ 3.2 ms ] story [ 104 ms ] threadMicrosoft deploys over 500,000 Java Virtual Machines (JVMs) internally – excluding all Azure services and customer workloads – with needs that go from back-end microservices to Big Data systems, message brokers, event streaming services, and gaming servers. More than 140,000 of these JVMs are already based on the Microsoft Build of OpenJDK.
[1] https://en.wikipedia.org/wiki/Apache_Kafka
I do not know why microsoft dupplicates this effort.
Why do you say they are duplicating efforts?
The builds on the RedHat page are for: x86 (32-bit), x64 (64-bit x86) but any mention of aarch64, which is what Microsoft has been working on with Azul Systems, is conspicuously missing.
(aarch64 or ARM64 is the 64-bit extension of the ARM architecture.)
Meanwhile most Microsoft shops view any non-MS technology as if it were a plague.
But that is just interop/language translation beyond stone age C ABI like most languages do.
ARM chips offer customers lots of cost savings in cloud environments than the more common workload of Windows on 64-bit Intel chips.
Their OpenJDK 11 builds are x64 for Windows, Linux, and macOS: https://www.microsoft.com/openjdk
The link is 404
The link works correctly only after logging in to GitHub.
EDIT: after logging out I can now see the link so it seems like it was indeed a permissions issue.
Hence I wonder if there is a vendor that has found the optimal configuration e.g -03 + x86-v3 (AVX) + LTO + PGO (e.g autofdo) + BOLT
Most vendors use pretty similar build toolchains in order to maintain platform support baselines. Typically any improvements get made at OpenJDK and then filter back down to downstream distributions.
One of the things we're looking to do is to add Metadata to the release to make the exact toolchain transparent going forward.
There's never been any question about the JDK/JVM license. There are tons of different ones that are all compiled from OpenJDK sources and offered for free (Amazon Correto, Azul Zulu) or licensed out with commercial support (Azul Zing).
The precedent matters.
I'm again willing to accept coincidence here, but doubt will be eternal.
> Microsoft Build of OpenJDK 11 binaries may contain backported fixes and enhancements we deem important to our customers and our internal users. Some of these may have not yet been formally backported upstream and are clearly signposted in our release notes. This allows us to expedite improvements and fixes much faster while we proceed to upstream those changes in parallel. Updates will be free and available to every Java developer to deploy anywhere.
I wonder how badly Oracle's attempt to monetize Java is going.
They're selling support for the JDK to companies that value that service.
I'm guessing they're doing OK on that front, since the sorts of enterprises that typically buy support are their bread and butter.
The OpenJDK binaries 9+ available at jdk.java.net are built by Oracle and some versions are not really "pure" because Oracle deliberately chose to exclude Shenandoah GC (Red Hat) from their binaries hosted on this site. [1]
Meanwhile, the binaries available on the Linux systems listed in this page (versions 8 and older) are all built by the Linux distributions teams, and not by Oracle.
Pure OpenJDK builds are those that are created from the source code and with all the features enabled (including all the GCs available), and ideally built from a single vendor/entity.
If you want "pure OpenJDK builds", your best bet is AdoptOpenJDK (now known as Eclipse Adoptium). [2]
[1] https://developers.redhat.com/blog/2019/04/19/not-all-openjd...
[2] https://adoptopenjdk.net/
Now that OpenJDK is GPL-ed, they can add anything they want! And of course - they will not try to put the changes upstream, because this is not "extend" anymore...
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
sdk install java 11.0.10.9-ms
Sun, Oracle, BEA, IBM, Excelsior, PTC, Aonix, Aicas, Fujitsu, HP, Nokia, Sony, Azul and to certain extent Apple (for a while it was the Swift of OS X), Microsoft (until J++ venture turned into C#)
I'm fine with the general attitude of harmony and oh yay, a bigger tent for everyone, it doesn't bother me, and platform flexibility has it's upsides. But there really is a downside to this all too, and it goes unremarked. I want to at least put down some words, somewhere, to remark that Windows support is constraining & limiting. OpenJDK of course is cross platform & already supports Windows, but the sign that this is a proper & well supported thing in Windows will quite likely amplify Windows user's expectations that all the libraries & tools they run across are going to be catered to them & their experience. It increases a library maintainer's burden, supporting this new class of usually-not-that-expert users. I encourage us to reflect on this as a mini Eternal September event, of Microsoft extending the reach of their community into something that used to be a little more deliberate; that's maybe putting it a little strongly, but I think we can recognize the parallel.
To summarize, are more prevalent technical constraints, and re-emphasized demands upon open-source Java authors, in this shift to further allow & encourage Windows based Java development.