Understanding Platform Core

Hello and welcome to this overview of Azul Platform Core, our Zulu builds of OpenJDK. My name is Simon Ritter. I’m the Deputy CTO at Azul. Now, in order to understand what it is we’re offering in terms of Zulu, we need to talk a little bit more about what OpenJDK is. OpenJDK is an open source project that was started back in 2006 when Sun was still the company behind Java. And the idea here is to allow people to contribute ideas to the future of the Java platform in the form of bug fixes, in the form of new features and so on. In addition, it allows for people to use that source code and then to create their own distribution of the Java platform so that people can use that. If we look at the way that distributions happen, as I said, we have the OpenJDK source code in the middle. And this is really the very important thing, is that it is source code only. Different people will join projects within OpenJDK and contribute to the features of that, as I say, through bug fixes and so on. And the majority of those features will come from Oracle as the owner of the intellectual property associated with Java. But lots of other people. companies and individuals will also contribute. People like the engineers at Azul, Red Hat and Amazon. Within OpenJDK each version of Java has its own project and if you want to create a distribution you can download the source code from that project and run the build scripts which allow you to then create the binaries that are required to run your application. That’s the important distinction. OpenJDK is the source code the distributions that are created are the binaries that you can install on your machine and then run your Java applications on top of that. And different providers of distributions will do that in the way that they want to in terms of whether they add new features or additional features and also the level of support and how long they will provide updates to the particular distribution that they have. One of the things that has changed more recently is the way that the versions of Java are supported for extended periods of time. In the past, it used to be that the current version of Java would have updates and the previous version would also have updates that would overlap for a couple of years, maybe, allowing people time to migrate from one version to another. In 2018, with the launch of Java SE 9, the idea was to change from having multiple years between releases to having only six months between those versions. And this led to a decision which was that it wasn’t practical to provide extended support for all of those versions. To allow people to continue using older versions, the decision was made to introduce long-term support versions. At that time many people were using JDK 8 and it was decided that would be a long-term support version. The next one after that was JDK 11 and initially it was going to be three years between LTS releases, so JDK 17 is the current one and that’s now changed to two years between long-term support releases, so JDK 21 will be the next one. In terms of providing updates to these older versions, the long-term supported ones, the important critical part is providing security patches to enable you to have the maximum level of security for your applications. And this is handled through the OpenJDK and it’s handled through the OpenJDK vulnerability group. Even though this is an open source project, the OpenJDK vulnerability group is actually a closed group. reason being that because we’re dealing with security vulnerabilities that haven’t been fixed yet it’s very important that details of that don’t get publicized and allow people to then try and exploit those vulnerabilities. The vulnerability group consists of all of the main companies and individuals who provide distributions and they work together collaboratively to generate the security patches to address those vulnerabilities. In terms of being closed all of or that group are encrypted and there is publication of the emails within that group. Another very important thing is the way that Java is specified. This is done through the Java community process that’s been around since 1999. The idea here is to provide an open specification that people can look at, and if they want to implement their own version outside of OpenJDK, then they can. Each version of Java is defined by a Java specification request, and that consists of three things. First is the specification itself. and that is a definition of the language syntax, it’s a definition of what the JVM needs to do, and it’s a list of all the class libraries that are included as standard. The second part of the JSR is a reference implementation and that’s designed to show that the specification can actually be implemented. In the case of Java SE, the reference implementation is OpenJDK, the open source version of Java. The third part, very important one, is the technology compatibility kit. What that does is to provide a set of tests, in this case over 150,000 tests, which can be used to verify that a distribution that’s been created matches the specification. So this does two things. Firstly, it verifies a distribution as conforming to the specification, but it also ensures there’s no ambiguities in terms of the specification. If we look at Azul platform core specifically, what we do here is to provide you with builds of OpenJDK with extended support. And in terms of the versions that we provide. we go all the way back to JDK 6. This is the first version that’s available through OpenJDK. You can see from the list here that we provide updates for JDK 6, 7, 8, 11, and 17, which are all the long-term support releases. In addition, we classify JDK 13 and JDK 15 as medium-term support releases and have extended support for that. One of the other very important things about what we do… for Azure Platform Core is for each update we provide two versions of that. This is the same as you would get from Oracle and we are the only distribution provider that does this other than Oracle. The idea behind those two versions of the update is that the first one is called the security only update or in Oracle terminology the critical patch update or CPU. This only contains the security patches for that particular update. The idea being that if there’s a critical vulnerability that needs to be addressed very quickly, you can use that with minimal set of changes, do some quick testing of your applications and deploy it to get your applications as safe and secure as possible. The second version is a superset of that called the full update or again in Oracle terminology the patch set update PSU which is all of those security patches plus everything else and that would be any bug fixes, any performance improvements and things like that and that could be several hundred different changes versus only a couple of dozen changes in terms of the security update. With the full update you can take more time to test your applications to make sure there’s no issues in terms of stability and then roll it out when you’re happy with that. The security update gives you the maximum level of security, the full update gives you the maximum level of stability. In terms of the main features that you get with Azure Platform Core as a supported version of Java, we give you TCK tested binaries wherever possible. Both JDK 6 and JDK 7, because they’re so old now, Oracle no longer provide commercial support and they’ve withdrawn the TCK license for that. All other versions from JDK 8 onwards are fully TCK tested. We provide all of the updates within a time defined SLA. There are four updates each year, January, April, July and October. We will provide those. within a very quick time from when Oracle released theirs. In fact if you look at our history we’ve done that within one hour of when Oracle released the embargo on people providing updates. We also guarantee that we provide all security patches and all bug fixes back ported to older versions where applicable. Obviously if there’s a new feature in the current version that isn’t in one of the older versions we don’t have anything to backport but all applicable patches and fixes will be backported to the supported versions. As I mentioned, we provide those two different versions of each update, the CPU and the PSU, so you’ve got the maximum flexibility in terms of how you deploy that update. And the last thing is that we also provide a traditional support organization. If you have an issue, you can report that to our support organization, raise a ticket, and we will respond very quickly to acknowledge receipt of that ticket and start working on a fix for you. So the idea behind this is to provide you with the maximum level of security, the maximum level of stability and the maximum level of flexibility in terms of deploying Java for running your applications, using older versions and still being able to update them and keeping them secure and stable. And so with that, that is an overview of Azul Platform Core, our Zulu builds of OpenJDK.