Use your budget to build apps. Not Oracle’s piggy bank.

CALCULATOR

See what you'll save by switching from Oracle Java SE to Azul.

Calculate Savings >

Oracle Java SE vs the Challengers

How Oracle Java compares to Azul Platform Core, Red Hat OpenJDK, Amazon Corretto, and AdoptOpenJDK.

Explore Java Alternatives >

Leave lag and latency behind with a hyper-optimized Java runtime

Break performance boundaries and deliver incredible value.

Explore Prime >

Review of Oracle's pricing change

Simon Ritter:  Yes, absolutely. What's happened is that probably about four or five years ago now, Oracle decided to change the way that they licensed the Oracle JDK. And that's the one that really people have been using pretty much everywhere because it was free. And they decided to change the licensing so that now it was under a license which said that, if you wanted to use it for development, if you wanted to use it for testing or personal use, then it remained free. But for other situations where you were using it in a commercial environment to run your applications within your enterprise, then you needed to buy a Java SE subscription, and that was what you would pay to get the updates and you would get support for the Java Runtime.

Now, when they did that originally, the way that the pricing worked was they looked at a very logical sort of approach, which was how many machines were running Java. And they would price it based on the number of cores within each machine. So it would take how many processes you have, how many cores you have. And then there was a slight complication to that where you had a multiplier for the number of cores based on the type of core that you had. So the more modern the processor, the higher the multiplier. And then they would use that number to then figure out how many licenses in effect you would need to buy for your subscription. For desktops, it was slightly different, they would simply count the number of people running on a desktop and how many desktops there were, and that was the way they'd create a metric for that. So that was quite logical because it really priced on usage.

What they've now done is they've said their customers are asking for a more simple way of doing this because figuring out how many cores they had, and how many users, and so on. So now they've come up with a very simple metric, which is to say, "We will simply base it on the number of people in your company." So number of employees in your company. And that means the full-time employees, part-time employees, and contractors. And then just to add a little bit more to that, if you have IT outsourcing, then you also need to include any contractors or staff who are actually helping you from an outsourcing point of view as well, and that clearly can lead to a much bigger bill in terms of your Java usage than you would've had before based on just how many machines and how many desktops you had. So that's really the crux of it.

Elise Cox:  Okay, so I understand a number of customers of Oracle have been very alarmed by this new pricing and have shared their alarm with groups like Gartner and Forrester. We've heard also in the course of offering an alternative to Oracle, we've gotten some questions from people about the Oracle pricing who are looking just for advice. One of those questions is, so we have a Java SE subscription, will we need to switch to the Java SE Universal subscription, that name for the employee metric based subscription, when we renew?

Simon Ritter:  Yes. So according to Oracle, essentially, yes. When you come to renew, you will need to switch from using the Java SE subscription to the Universal subscription, which is this new pricing model. Now, we need to be a little bit careful about that because also if at some point you were to decide that your usage had gone up and you now had more machines or more users who were using Java and you needed to then go back to Oracle and say, "Well, actually, we need more licenses for that." That would then automatically count as a renewal and you would then have to switch to the new pricing model at that point. So either when the current contract you're on comes up for renewal at the end of that contract, or if you need to change the terms of your contract, then that would then also count as a renewal. So there's two different situations where you would need to move to the Universal subscription from the Java SE subscription.

Who is and who is not affected by the Oracle Pricing Change?

Elise Cox:  Okay, that's really helpful. Customers really seem to be honing in on, am I affected by the pricing change? Who is not affected by the pricing change?

Simon Ritter:  Right. So the licensing that Oracle use varies very much depending on which version of Java you're using. And when we talk about Java here, we're talking about the Oracle JDK specifically, because if you're using a different distribution then clearly the licensing and pricing terms are different. But if we talk about the Oracle JDK, then if you're using Oracle JDK six or JDK seven, for example, which are the oldest versions that were under OpenJDK, then those are no longer supported by Oracle, so you wouldn't have to have a subscription for that because there wouldn't be any further updates from Oracle. JDK eight is sort of a hybrid and that makes life a little bit complicated because up until January of 2019, the license that they used for that was the older free license that only required to pay for a license if you were using it in embedded applications.

So up to January 2019, which is update 202, then you don't have to pay for a Java SE subscription. If you're still using Java eight and you have updated to the latest updates, so anything from update 211 onwards, which was in April 2019, then you would need to be under the Java SE subscription if you're running in a commercial environment. JDK 11 is also under the same terms and conditions, so that means that you would need a Java SE subscription for anything in Java 11. To make your life more interesting as a Java user, Oracle then changed the license that they use for JDK 17 and subsequent long-term support releases. What that means is if you're using JDK 17 at the moment, then they extended the places where you can use it for free under what they call the No-Fee Terms and Conditions. And the No-Fee Terms and Conditions says that, in the same way, if you're doing development, if you're doing testing or personal use, you can use it for free.

But then they also extended it to say that you could use the Oracle JDK without buying a Java SE subscription if you were using it for internal business applications. So you need to be careful that... Obviously, internal means running your own business internally. But if you had somebody, say, running a web server that was accessible outside of your business to your customers, then that might not be considered as an internal business application by Oracle. So in terms of who is not affected by the pricing change, essentially anybody who's still using JDK six or JDK seven because they're not getting updates. Anybody who's using old versions of JDK eight because they haven't updated recently, and so are exposed to lots of security vulnerabilities. And anybody who's using JDK 17 and is only using it for internal business applications. So it is quite complicated understanding all the different nuances of this.

Elise Cox:  Okay. It is complicated, but you did a great job. It seems that if you are using Oracle for internal business applications, you could still get that call from your Oracle rep like, "I want to talk to you about your Java usage." And they would want to see proof that you're only using it for internal Java applications. Is that a reasonable assumption to make?

Simon Ritter:  I think so. What we've heard from customers is that Oracle are being a lot more, let's say diligent is probably a good word to use here. They're being a lot more diligent in requesting information from customers to verify what their Java usage is and where they've used different versions of Java and so on. And they're also using download information, again, from what we've heard from customers. They're using download information to say, "Well, we have record that IP addresses that are registered to your enterprise have downloaded copies of Java from our website, and they are versions which are covered by the Java SE subscriptions." So they would like proof to show that either you have paid for the Java SE subscription or you are not using them in a way that would require one. So again, you need to be quite careful about how you're using Java.

What happens if I don't renew my Oracle subscription?

Elise Cox:  Yeah, there's lots to think about. So customers have asked or prospects have asked, "What happens if I don't renew my Oracle subscription?" So they're like, "Okay, I've had enough of Oracle right now." But what happens if I just say, "I'm done. I'm not renewing."

Simon Ritter:  So there's two things to consider there. The first is that if you decide that you're not going to continue with a Java SE subscription or switching to the universal subscription, then you would have to stop using any of the copies of Java, Oracle Java, which would fall under the Java SE subscription. So that would be, again, the more modern updates of Java eight and Java 11, or even Java 17 if you were not using it for internal business applications. So you would be forced to remove those copies of the effectively licensed software.

Now, you could do that by replacing them with a different distribution of OpenJDK. And so since this is an Azul webcast, obviously I will mention the fact that we have our builds of OpenJDK, which we call PlatformCore or Zulu, as the actual distribution is called. And you can install those instead. So you could take the PlatformCore, Zulu builds of OpenJDK, you could install those on your machine instead of the Oracle JDK, and then you could run those and have your applications run in exactly the same way. So there is a alternative in terms of how you do it, but it would require work. If you decided to stop using that then you would need to make a decision about how your strategy for using Java would move forward.

Is it easy to migrate off of Oracle Java SE?

Elise Cox:  Okay. I know that the Oracle reps like to talk about how difficult it is to get off of Oracle Java SE, but my understanding is it's really not that difficult. In some cases it's just really, you change the pointer to the... Could you talk about that for a second?

Simon Ritter:  Yeah, absolutely. If you look at the way that Java is organized, you've got OpenJDK, it's an open source project. And the way that I like to talk about this is always to use the analogy of Linux. Now, Linux is an open source project, people contribute to it, there's lots of ideas and source code. But if you want to use Linux on your machine, you don't download the source code and build your own Linux kernel, you use a distribution from somebody like Red Hat, or Ubuntu, or whoever. Now, the same thing applies with OpenJDK. Oracle are using the OpenJDK source code to build the Oracle JDK, and that's what people obviously are using a lot at the moment. But there's no reason you can't switch to a different distribution, like Zulu, where we take exactly the same source code as Oracle do, and we download it, and we build it using the same build scripts and so on. And we generate a binary distribution that you can install and run your Java applications on.

Now, in order to give you a higher level of confidence that what we're providing is identical to what Oracle would provide you with, part of the Java SE specification, and that comes from the Java community process through a what's called a JSR, or Java Specification Request. Part of that is a thing called the TCK, and that's Technology Compatibility Kit. That's a set of tests that you can use to verify that your binary distribution matches exactly to the specification that's been defined for that version of Java. And if you look at how many tests there are, it's anything up to about 150,000 tests. And you have to pass every single one of those to show that you're a conforming implementation of the standard. So the idea is that if you're moving from one TCK tested Java Runtime, which would be Oracle, to another TCK tested Java Runtime, in this case Zulu, there are no differences from a functional point of view. Your applications will run in exactly the same way.

There's no requirement to change any of the source code, there's no requirement to recompile your applications. As you said, you can simply install the new version of Java from a Azul and either manually redirect it to point at where the installation directory is. Or if you use the automated installation scripts for things like an MSI file for Windows, or an RPM or a dev file for Linux, that will install the new Zulu package as the default Java, so applications will then pick it up by default. So from a server perspective, that's really very straightforward, it's very simple. There isn't anything to really consider. We do have a couple of things when you're dealing with desktops because there are a couple of deployment technologies which are included in the older Oracle JDK, so JDK eight and earlier, but they're not part of OpenJDK. They weren't open source at the same time as the rest of the Java platform was.

The two that you need to be aware of are applets, so if you're still running those very old applets from the dawn of time, 25 years ago, then there isn't an applet browser plugin that comes with OpenJDK. Same thing for what's called Java Web Start, which is used for deploying applications on desktop sometimes. Now, in the case of Java Web Start, there's an open source alternative to this, which is called ITWeb, which can be used as a replacement that may take one or two configuration changes just to make your application work with that, but there is an alternative. So server side application, very, very simple, straightforward, it's just like for like, drop in replacement desktops. If you're not using applets, if you're not using Java Web Start, same thing, very quick, easy for Web Start, then you may have to do a little bit of work to reconfigure things to use ITWeb.

How Azul helps with Java modernization initiatives

Elise Cox:  Okay. Thank you so much. That was really clear. I think I understand that completely now. There's a new survey on the state of Java that came out, I think over the weekend, and increasingly people are moving away from desktop applications. It seems like we can also help them with their modernization initiatives as well.

Simon Ritter:  Mm-hmm. Yes. What we've seen is obviously that the origins of Java go all the way back to when we started adding the ability to include programmatic functionality into the browser. It used to be the browser was very static in terms of webpages, and suddenly you could put an applet into your webpage and have dancing dukes, and forms, and all sorts of things like that. We have moved on a lot since then, so we now have HTML5, we have JavaScript that's used pretty much ubiquitously, and we have CSS as the combination of things that are used there.

And that means that anybody who's developing a web-based application is going to do it through those three key things. They're going to use HTML5, JavaScript, and CSS most likely. There are still some desktop applications where they've got very complicated graphics. If you're doing something like a trading application used in financial banking, that kind of thing, those may well still be written in Java, they may still run as a desktop application. But they won't be using applets, they won't be using Java Web Start, they're an installed application, which again, doesn't have any issues in terms of migrating to a different distribution of Java. So yes, most desktop applications have moved away from the idea of using Java in the way that it was originally designed.

We are running the free version of Java 8, do we now have to license Java based on employee counts?

Elise Cox:  Okay. A couple questions, just wanted to cover these even though we've touched on this already, but I think this person may want just a yes or no answer. And I'm not sure if we're able to do that, but let's try. We are running the free version of Java eight, do we now have to license Java based on our employee counts? This is someone who's concerned they haven't... Yeah.

Simon Ritter:  Yes. So if they're running the free version of Java eight, that means that they're running update 202 or earlier, so that means that they're running a four year old update of Java. And there's no requirement for them to switch to using the new Java SE or Universal subscription, unless they wanted to update their Java to the latest update. Now, in that particular situation, I would strongly recommend to the customer that they should be much more concerned about the security of their applications running on that very old update of JDK eight, rather than the issues of are they exposed to licensing and so on. So what they really should be thinking about doing is, "Okay, we need a different distribution of Java. We should switch to that so that we're not having to pay the Universal subscription for Java SE. And then we can also update to the latest security patch." And that will mean that you're not exposed to quite a significant number of vulnerabilities that have been addressed in all of the updates since then. So four years of updates is quite a lot of security vulnerabilities that you will be exposed to.

Do any of the Azul products phone home?

Elise Cox:  We have a question in the chat. Do any of the Azul products phone home?

Simon Ritter:  They do not, not in the sense where it's a sort of licensing thing. Now, what we have done more recently is we have created a new product that's built around our PlatformCore and also our Platform Prime, and that's what we call the Azul Vulnerability Detection. The idea behind that is that because we build the Java virtual machine, we build the Java Runtime, we can use a lot of the information that's already collected by the JVM as part of running an application to, in effect, monitor where you might be exposed to security vulnerabilities. And what we do there is we say, "Well, we can see all of the classes that are being loaded by the JVM." As you start your application up, you'll load classes from JAR files and so on. And as the application runs, you also potentially have dynamic class loading as the application continues.

Now, because we can see all of that information, we can then make that information available to a way of monitoring that. But it's not a phone home in the sense that I think the attendee is asking the question here. The phone home kind of thing would be where it's literally saying, "Okay, you're running this application, we need to monitor that and find out where you're using it." So we don't do that at all. The Azul Vulnerability Detection is something you have to explicitly turn on to say, "We're going to use Azul Vulnerability Detection, so I want to turn that on and give the IP address of where the information will be sent to in terms of collecting it." So we can provide a cloud service externally, or if you want to deploy it in within your own data center, inside your firewall, then you can do that. So there is no phone home type of functionality in the sense that other companies use to monitor licensing usage and so on.

Does Oracle Java phone home?

Elise Cox:  Can you maybe provide a little bit of insight into, does Oracle phone home? Of the Oracle Java products, do they phone home?

Simon Ritter:  I believe there is some phone home in there, but I think... That's one of those questions where I think you would need to actually ask Oracle that question to see whether it's something that they build into their functionality.

Elise Cox:  Okay. The concern, I think, with the phone home is that the information can be used against you.

Simon Ritter:  Yes. This is one of the problems that people are facing, is that because of this new pricing model where essentially they're saying that the way you pay for Java is based on the number of employees that you have in your company. What that means is if you only use one instance of Java, then you have to pay for every employee in your company to use Java, even though it might be only one person. So this is where the phone home functionality would become an issue because if somebody downloads a copy of Oracle Java, starts up an application and it does phone home, and then that provides information to Oracle to say, "Yes, you've used our Java." Suddenly, you have to then license everybody to use that one copy of Java. So it would be quite significant.

Elise Cox:  So the person also, he just dropped a note in the chat, I don't know if everyone can see it. But if you go to java.com and then slash EN, so for English, slash data, you can find out about what usage metrics Oracle is collecting and how they're using it. So that would be a good place to go, guys, for that. We also, I just think it's important for people to understand, so we don't audit. We don't have the right to audit in our contracts and we don't audit. We trust our customers.

Simon Ritter:  Yes. It's important to explain, again, coming back to licensing issues, because the Oracle JDK uses these different types of license. So the original license that they used for JDK six, seven, and the early updates of JDK eight, is what's called the Oracle Binary Code License. And that grants you free use of the Oracle JDK, except when you're using it for embedded applications or single purpose applications like a ticket kiosk or something like that. Then they introduced the second license, which is called the Oracle Technology Network License Agreement, which is much more restrictive in terms of where you can use it freely. Development testing, Oracle approved applications, Oracle Cloud.

And then they have a third license, which is the No-Fee Terms and Conditions, which then says that if you are using it for internal business applications, then you can still use it for free. Now, the reason I go through those three things is because if you look at the license that we use for Zulu, it is the same as Open JDK. So it is the GPL version two with classpath exception, which means that you're free to use it wherever you want, there is no counting in terms of the auditing, as you say. Because what you're effectively buying with our PlatformCore is the support around that. So it's not that you're paying for licenses to use Zulu, you're paying for, in effect, the support of those instances of Java.

Elise Cox:  Okay. So we do have a comment in the chat that this attendee says, "Oracle is using the information for licensing." And I would just, again, direct people to want to know more to java.com and then slash EN slash data. Maybe I can send to everyone. I'll just put this... Yeah, sorry guys. I'll put this in the chat. So a couple more questions moving beyond the phoning home. Again, a lot of these questions have to do with, so whether or not this organization, the organization of the person asking the question will be subjected to the licensing. Some of our Oracle applications use Oracle JDK, so do we need to license Java based on employee count for these particular applications?

Simon Ritter:  Right. Yes. So if you have things like Oracle's WebLogic, for example. WebLogic is the application server, it runs on top of the Oracle JDK. Now, in that case, what typically happens is that you have the Oracle JDK bundled with the license for WebLogic, and so it's different in terms of how that is licensed. So again, as a non-Oracle employee, I would refer you to look at the license specifically for that application that you have from Oracle. So you would need to check very carefully in terms of the license that's provided for WebLogic or whichever Oracle application it is, to make sure that the Oracle JDK is included in that, and that you're not required to then buy a separate either Java SE subscription or Universal subscription for that.

We are running Cassandra on Java 11, if we expand our usage will we need to license Java based on employee counts?

Elise Cox:  Okay. So another common use case, we're running Cassandra on Java 11, so if we expand our usage will we need to license Java based on our employee count?

Simon Ritter:  Yes. So if you're using Java 11, the Oracle JDK 11, then that is covered by the Oracle Technology Network License Agreement, which requires you to buy a Java SE subscription. If you were to change and expand the usage, that's when, as I said earlier on, it effectively becomes a license renewal situation. So even though you may not be at the end of the license term that you already have, because you're changing the usage, that then becomes in effect a license renewal and then Oracle would want you to switch to using the Universal subscription, which would require you to pay based on the number of employees in your company.

Elise Cox:   So here's another question for you, Simon. So this company running Cassandra on Java 11 decides to update to Java 17, or maybe they're going to update to Java 21 in September. So for how long do they have the Java SE for free? And then what happens? Do they automatically transition then to the Java SE Universal, which is employee count metric?

Simon Ritter:  Mm-hmm. Yes. So again, the licensing gets even a little bit more complicated than we've already said, which is that if you're using Java 17 or you decide to switch to Java 17, the license for that is currently the No-Fee Terms and Conditions license. But what Oracle have said is that the No-Fee Terms and Conditions license will only be applicable until one year after the next long-term support version of Java is released. Now, when JDK 17 came out, they switched from having three years between long-term support releases, which was JDK 11 to JDK 17, to only two years between long-term support releases.

So we had JDK 17, and the next LTS release is JDK 21. And as you said, that's coming out in September this year. What that means is that from September of next year, September 2024, the license for JDK 17, Oracle JDK 17, will switch from the No-Fee Terms and Conditions back to the Oracle Technology Network License Agreement. So at that point, if you're still continuing to use Java 17, you would need to switch to using a Java SE subscription, even if you're using it for internal business applications because that's not covered by the Oracle Technology Network License Agreement. So you would need to switch to having a Java SE Universal subscription at that point, and that would require you to pay based on the number of employees in your company.

Elise Cox:  Oh, so that's really interesting. I think that that's a point that people are missing, is that everyone will eventually... Well, people who want to move to more current versions of Java will also be moved to this Oracle Java SE Universal subscription.

Simon Ritter:  Yes.

We have Java applications running on Oracle Cloud infrastructure on AWS and Azure, does the new pricing apply to us?

Elise Cox:  Okay. So we have Java applications, I'm going to read another question from folks. We have Java applications running on Oracle Cloud infrastructure on AWS and Azure. So does the new pricing apply to us? So they're basically multi-cloud.

Simon Ritter:  Mm-hmm. Right. So yes, if you're using the Oracle JDK in the Oracle Cloud, then that is included in your cloud subscription, so you wouldn't need to pay anything extra. So if you're using the Oracle Cloud and you're running Oracle JDK to run your applications, then you're covered with that. If you're using AWS and you're using Azure, then if you were to use the Oracle JDK in those cloud, if you were using it as a infrastructure as a service and you installed the Oracle JDK onto AWS or Azure, then yes, you would be required to buy a Java SE subscription. But that said, most people wouldn't do that because if you are running on AWS, then you get Corretto is included in the price of your subscription. Corretto is a distribution from Amazon. And if you're running on Azure from Microsoft, then Microsoft have their own JDK distribution that they provide as part of that, so that you can use that within the Microsoft Cloud. So you would typically use different JDKs, depending on which cloud provider you are using.

Some of our customers do decide that they want to use Zulu because it means they have a single Java Runtime across all cloud platform. So if you are running a multi-cloud strategy, then we do have some customers where they say, "Well, let's just go with one JDK and we'll deploy it on Oracle, we'll deploy it on AWS, we'll deploy it on Azure, and then we don't have to worry about differences between any of the builds."

Critical Patch Update vs. Patch Set Update

Elise Cox:  And also, there's those old track record for getting the updates out very quickly, and also of offering the stabilized security builds, which I believe we're the only ones who do that.

Simon Ritter:  That's right, yes. If you look at what you get in terms of updates from Oracle, you will receive two different types of update. There's what's referred to as the CPU, or the Critical Patch Update, and the PSU, or the Patch Set Update. Now, the CPU only includes changes that relate to security vulnerabilities, so it's a subset as a small set of changes. And then the PSU is the security changes, plus everything else for that update. So that's bug fixes, performance enhancements, any other changes. Now, the reason for having this is that if you have a situation where there's a critical vulnerability addressed in a particular update, what you want to be able to do is to deploy that update as quickly as possible to your machines to ensure that they have the maximum level of security. By having the CPU, which is only the security changes, that tends to be a very small set of changes. If you look back over the last few years, it's anywhere between one, two, or up to maybe 15 or 16 actual changes.

If you compare that with the PSU or the full update, what you're looking at there is two, three, even 400 changes versus 10 changes that you get with the CPU. And that means that the potential for impact on stability is much less if you deploy the security only update. What we've seen, certainly over the last four years, is there are situations where an update is released and it includes a fix to a particular bug that has been reported in the full update, the PSU. And that introduces a regression that can affect certain applications. And the example I like to use of this is if we go back a couple of years to July 2020. In the full update, there was a fix, which again, fixed a bug, but it meant that software packages like Hadoop cluster, Solr, and Lucene literally wouldn't start with that update installed. And that means that you then can't install the update with the security patches unless you've got that CPU, the security only update, which didn't include the fix that broke things.

And we've seen that several times over the last four years where that's happened. As you say, in terms of what we provide from a Azul for our PlatformCore, we provide both the CPU and the PSU the same that Oracle does, and we are the only distribution that does that. Everybody else will only provide you with one update, which is the full update. Meaning that if there is a regression that affects stability, you will have to wait until that regression is fixed. And again, going back to that example of 2020, that took two weeks for the fix to come out. And that means that you're exposed two weeks of all the security vulnerabilities that have been reported against that particular update, where people can try and figure out, and exploit, and then search for machines that have that exploit available, and then try and attack them. So it's very important to be able to have that, both the security only update CPU, as well as the PSU.

Elise Cox:  Yeah, I don't understand how anyone who is running business critical applications would make the risk of going to the PSU.

Simon Ritter:  I do find this is very interesting. We talk to a lot of customers and potential customers and one of the things that is quite a hurdle for people is getting over the idea that Java is no longer free in terms of updates and support. And because we've had free Java for so long, people have got very used to that and that's what they expect. But it's not realistic in many ways because if you think about it, if you're running mission-critical enterprise software, then really you should have supported software. If you're running Windows, if you're running Linux, then you're going to be paying a support contract to make sure that if there are any problems with your Windows or your Linux, you've got somebody to go to, somebody that will help you with that and make sure you get all of the security updates on a regular basis.

The same with if you're using Cassandra or if you're using Kafka, it's open source software. But most likely you'll be running software from somebody like DataStax or somebody like that, and it will have a support contract and you will have supported software. So it's interesting that people don't feel that Java should be a supported piece of software, it should just be free and just use it. If you're running mission-critical applications, Java is a critical piece of that stack and it needs to be supported in the same way the rest of it is.

Elise Cox:  It's interesting because it's not really free, but what they're doing is that they're contributing bug testing, so they're bug testing these new releases and they're not counting the time of these regressions necessarily. They're not necessarily figuring out, "Well, how much did that cost me?" And those questions can be tough because it's not just employee time, it's also the downtime. So it's interesting. It does seem to me that it's worthwhile to be paying for these stabilized builds.

Simon Ritter:  Yes. Absolutely.

Elise Cox:  And I'm surprised that more providers aren't offering them. It's really just Azul and Oracle right now.

Simon Ritter:  Yes.

Is Azul typically 70% cheaper than Oracle?

Elise Cox:  We just have a moment or two, but is it really true that we're typically 70% cheaper?

Simon Ritter:  Certainly based on the new pricing or even on the old pricing, yes. One of the things that we at Azul do is we offer an identical, if not better service, that you would get from Oracle. So we provide identical builds in terms of functionality, TCK tested, very easy to switch between them. We provide both CPU and PSU, as you've already said. We can even provide, as I say, a better service because we still provide updates to JDK seven and JDK six. And there are a lot of people out there still using those older versions of Java and they're not in a position to be able to migrate to a newer version.

For them to be able to continue with the security patches where applicable is very useful because they don't have to go through a lot of extra work, so we can do that. Plus we have a world-class support organization. We've got people who have a lot of experience of helping customers who do face issues with the way that the JDK works, and the installation, and all sorts of things like that. So that they can help them if there are issues that need to be addressed. And our support organization has 100% satisfaction rating. So yes, up to 70% cheaper than you would be paying with Oracle to get an identical service.

Does Azul have 100% customer satisfaction?

Elise Cox:  Okay. As a former journalist, I'm always like, when we say that 100% satisfaction, I'm like, "How can it be 100%? You've got to have at least one dissatisfied customer."

Simon Ritter:  Well, apparently not. We do survey our customers on a regular basis and we ask them, "Have you interacted with our support organization?" There will be a number of them who haven't interacted with our support organization. But for those who have interacted with our support organization, they have had their issues resolved in a timely manner to their satisfaction. And I know that one of the things, again, when I talk to Java users, a lot of people say, "Well, we've never had to contact Oracle with a problem in terms of the JDK, so why would we need a support organization in the traditional sense?" When I first joined Azul, I kind of thought to myself, "Well, that's probably right because I don't remember ever having a bug in the JDK that stopped my application working." But then when I look at our logs for our support calls from our customers, there's actually quite a few issues that get raised.

And some of these are things that are actually significant if you're running big applications and suddenly your application doesn't work in the way you expect it to. And our support organization are able to actually go in and create fixes for that, outside of OpenJDK, be able to create a fix for that so that we can provide an update independently to our customers that will address that problem and get their applications running again. Now, we're good open source citizens, so we will take that bug fix and we will then upstream it into the OpenJDK project, and make sure that other people can benefit from that as well.

But obviously, that will take time because it needs to filter through and then it needs to go into whatever the next update is. So it could potentially be three months before you get that fixed. Whereas our customers can have that immediately as soon as we've created the patch for it, we can then provide a special build and get them up and running again. So having the support organization behind you and that level of insurance in effect for your applications is also a big benefit of having the PlatformCore available to you.

Elise Cox: Okay. Simon, I think we're coming up on time and we have covered all the questions. I'll ask anyone else who's on the call, are there any other questions that are coming to mind that you'd like us to cover? Give them a minute. It's always wonderful to talk to you, Simon, because you have such a wealth of knowledge about Java, so thank you for everything you've done for Java also.