 So, hi everybody. My name is Volker Simonis. I'm working for SAP in the SAP JVM team. We are involved in the OpenJDK project since about 10 years. As Mark put it, we contributed some ports, Aax, PowerPCS 390. We're also contributing a lot of bug fixes, serviceability features and stuff like that. Well, recently there has been a lot of discussions about the future of Java. Is Java still free? What can we do? So hopefully this talk can bring some light into the Java story. So all these slides are on GitHub. I will show this slide at the end one more time so you can take a picture if you want. I have a lot of links in my slides so you can use it as a starting point if you're interested in these topics. So let's start very easy. What is Java? It's actually three different things. It's a programming language, a virtual machine, a runtime and a class library and API and all this together makes up the Java platform. But Java is also a trademark. So don't be afraid. This is the only blinking slide I will have. But this is very important because Java trademark is owned by Oracle and only they can use it. You can buy commercial license to use Java, but otherwise you stick to OpenJDK. Which is not bad. So what is the Java community process? It was mentioned in Mark's talk as well. It's actually a mechanism, a formal mechanism for the work on Java specifications. It's also around 20 years old now. And it's actually no standard body. So some people think it's like ISO or NC or stuff like that. But it's actually more of an industrial consortium and it's still dominated by Oracle, which is okay. Yes, and the JCP develops Java specification in so-called Java specification requests and the Java specification request creates a specification, a reference implementation and the TCK, which is a technology compatibility kit, which has the duty to verify that alternate implementations are conformed to the specification. So this is actually a good thing, I think, and it's quite unique among the different programming languages that we have, that Java and the Java ecosystem has very good TCKs. But there is also problems with this and we will see that. So I explained what a TCK is. The JCP has often be criticized as being just a rubber stump organization and that's partially true, but there have been situations, maybe the older here in the audience will remember the Apache versus Sun problems, where the JCP postponed Java 7 delivery for a lot of time and some people say that this was even the reason why Sun finally open sourced its Java implementation in the OpenGDK. And just recently the executive committee rejected the first version of the JSR376, which was the Jigsaw and forced the OpenGDK community to more thoroughly hear the community and bring some more changes to Jigsaw before they were finalized and released. So there is some advantages in having such a body. And actually the JCP cared for three different Java platforms. We had Java EE, Java SE and ME, which is a micro edition, and I already said that we had Java EE, so Java EE has actually moved out of the JCP out to the Eclipse Foundation and it's now called EE4J. Again, this is part of the reason for these name changes, because Oracle owns the trademark on Java, so it cannot be called Java EE anymore. It has its new name EE4J, which is quite nice, I think. JCP still cares about ME, but ME it's basically defunded. It hasn't happened anything there in the last few years, and I don't see any actions there, which is sad, but it's how it is. So currently JCP is actually only stewarding the Java SE development, and that's also what we will talk about in this second part of my talk. So what is the JCP? So JCP is Java compatibility, it's actually the TCK for certifying Java SE standardization conformance. But unfortunately, the JCP is only available to commercial Java licenses or to the OpenJDK community, which signs the OpenJDK community TCK license agreement, so-called OCTLA. But the problem is that with this, you can only certify JPL license implementations, which are substantially derived from the OpenJDK. And this term, substantially derived, it's a little fuzzy. For quite some time, Oracle was very handled this very freely, but recently there have been some problems, maybe you have read that Oracle withdraw the TCK from the DOP OpenJDK project, which used it to certify its OpenJ9 builds, which used a different virtual machine, the OpenJ9, combined it with the OpenJDK class library to create an alternative Java development kit. I remember it very well when we were here many years before, 10, 8, 9 years. There were other alternate VM implementations, JamVM, IKVM, I don't know, there were a lot of others, and they all used the TCK to certify, and it was considered substantially derived if they used the OpenJDK class library, but obviously this has changed with VMs, which are by a competitor like IBM. Another problem is JCK is that it's closed source, so the R-class actually and the A-agreement, so you cannot openly speak about the results or the problems, you can only communicate them back to Oracle. And while it's assessing that it's a good test kit for compatibility, you have to be aware that it's quite complex, it contains more than 140,000 tests, and the JCK 6 user guide, which is the only one which is available online under the Apache license, it's about 300 pages, which describes how to certify VMs, so you can have a look at it, certification is quite complex. And you have to be reminded conformance is not quality, so the JCK checks that your implementation is conformant, conforms to the specification, but it doesn't mean that your certification is high quality or it's stable or whatsoever, so you need different tests for proving quality. So what is the JEP process compared to the JSR process? JEPs were mentioned, the JSR as I told you is the Java specification request, which means how the JCP creates new specifications, and recently there is only one umbrella JSR for new Java releases, so all the features in Java are developed using the OpenJDK as JEPs, so the last JSR which specified a part of the SE platform was the JIC, so the modularization JEP, since then we only have umbrella, so-called umbrella JSRs, which contain all the JEPs, but JEPs are not developed using the JCP, but in the OpenJDK. So JEPs, JDK enhancement and proposal process, this is somehow still dominated by Oracle, because new JEPs require endorsement and funding by group leads, and currently all the group leads are from Oracle. You saw the picture, I mean Oracle also, 80% of the developers are from Oracle, so that's also maybe normal. Hopefully more and more contributors from outside will show up and maybe even become group leads to change that, and OpenJDK lead who sits here is the ultimate instance who decides which JEPs get included into a roadmap. So we have three kinds of JEPs, SE, these are JEPs that have to be approved by the JCP in the umbrella JSR, so SE JEPs change the Java platform standard edition specification. Then we have JDK scoped JEPs which change the interface, like add new command line options, add new classes, which are not in the Java namespace, maybe in the JDK namespace or ComSun or other classes, and we have pure implementation JEPs which maybe add a new GC or which add a new JIT compiler or improve the JIT or add a new platform port, so these are actually not visible through the interface. You see the functionality maybe faster, but you don't see the change in the interface. And this is the same slide which Mark showed. I think mine is nicer because they have colors. But what I wanted to show is so the green ones are actually the SE scoped JEPs which change something in the standard. So you see, for example, the process API update, this really added some new classes, Java, along with the process and functions to existing classes. Then we have the yellow ones which are the JDK scoped. So for example, we have a new Docklet API that's not standardized by the JCP, but it's still some classes which you can use in your project if you want. And then we have the white ones which are pure implementation scoped JEPs, like for example, the new build system or stuff like that or the Linux S390 port which was contributed by us. This is the same picture for Java 10, 11 and for 12. So you see, for example, 10 at very few, SE scoped changes local variable type inference, but this was quite visible change. And Java 11, which is a long-term release support, this brought in, for example, the new HTTP client as a standard. So when we go back, you see that in 9 we had the HTTP client as incubator module, which was not standardized, so we'll come to the difference between incubator modules and preview features in a few slides. Actually, just right now. So what are preview features in incubator modules? Incubator modules are defined by JEP 11. So the reason behind them is to ship non-final APIs with a JDK and in order to get feedback from the developers, improve this and finally standardize them. So this is a pure open JDK mechanism, so other VM implementers don't have to follow this. So, for example, if the Oracle JDK creates a new incubator module and you are developing your own JDK Java virtual machine, you don't have to also provide such a module. These modules are in the JDK incubator module or package. And actually, the reason behind this, you bring in an incubator module in a release and then it has to either be finalized and standardized in the next version or at least substantially improved. Otherwise, it has to be removed. So it actually should be like a one-shot example. If it's acknowledged by the community and people like it, you can finally standardize it or otherwise you can improve it if you get all the feedback or just remove it if it's not required. As I told you, this is not part of Java SE. And then with JEP 12, the processing introduced the so-called preview language and VM features. So this is actually a feature which is fully specified and implemented, but it may not be permanent. But this will be part of Java SE. So a preview language or VM feature will have its own SDK and everybody who pretends to implement this specific SE version will have to also implement its preview features. And they have to be enabled by the minus-minus-enabled preview frag. So by default, they will be switched off. And again, if there will be positive feedback, they can be made permanent. Otherwise, they can be removed in a follow-up release. Okay, so OpenJDK was mentioned here before. It's a Java SE reference implementation since Java 7. It's under GPL plus class plus exception, the class plus exception saves you from the viral nature of GPL so you can run your applications on OpenJDK without getting infected. Oh, sorry, I didn't have to say that. You have to inform me about your... Most of the people didn't hear anyway. But until OpenJDK 8, OpenJDK was a source-only project. So OpenJDK only provided the sources for the OpenJDK. Since Java 9, Oracle builds OpenJDK builds under GPL plus class plus exception, but only for Linux, Macs and Windows. So they don't build it on all the platforms supported by the OpenJDK, which has a much broader platform support. And they only do it for two updates, so for six months. But there are a lot of binary distributions from various other vendors, and I will present most of them, hopefully, at least all I know of. And they do different versions of the OpenJDK on different platforms. For different platform versions, you can choose the one you want. And then we come to the OpenJDK updates project. So this is actually the place where all three releases are maintained. So JDK 6, currently maintained by Azul, was previously maintained by Rhettat. JDK 7 maintained by Rhettat 8, so I updated this slide yesterday evening, by Andrew Haley Rhettat, very fine. JDK 9 updates, not maintained anymore in the OpenJDK project, but we will see there are other vendors who still support JDK 9 updates. It's Azul, for example. JDK 10, a short-term release as well, abandoned in the OpenJDK because nobody stepped up to take over the role of the updates project lead for JDK 10. Yes, and we all wait for Andrew to raise his hand for JDK 11. Okay, so Oracle JDK, it's derived from the OpenJDK. I would say substantially derived from the OpenJDK. So it had non-Java AC add-ons until Java 8, like Java FX. Web start, this is something which is very confusing for people who are now switching to OpenJDK-based distributions because many people thought that Java FX is part of the SE standard. I know it never was and it was never explicitly mentioned, but for many people, Oracle JDK was Java. It actually is Java, but not the Java AC platform. And it had commercial features like file recorder and mission control, which you could only use if you had a support contract. So until JDK 8 update 202, which came out, I think two weeks ago, the Oracle JDK was under the Oracle binary code license, which allowed you to use it productively. It allowed commercial use, but it still had a field of use restriction and this is also something many people were not aware of. So for example, you have never been allowed to use the Oracle JDK in embedded devices, for example on mobile devices and stuff like that. Now after Java 8 update 202 and for JDK 11 and ongoing Oracle JDK is under Oracle Technology Network license, which is for personal development use, but you cannot use it in production anymore. Okay, so this is one of my favorite slides. It may look a little complicated, but this shows the license flow. So in the middle, we have the open JDK, which is under GPR class bus exception and because Oracle is actually the owner, the copyright owner of the sources, they have the right to real license it and they actually do it. They do a licensing and for example, sell the open JDK licenses with the commercial. They just switch the copyright headers and sell it, for example, to companies like SAP or IBM. So SAP and IBM, they are free to do their own commercial Java distributions like we do, for example, SAP JVM, but SAP also contributes back to the open JDK. I mentioned that and we do that under the Oracle Contribution Agreements, which is actually a copyright sharing agreement. So we still keep the copyright on our contributions, but we also share them with Oracle and this allows Oracle to then real license our contributions to the open JDK to others so IBM can profit from our enhancements, we can profit from IBM's enhancement. And then everybody, also SAP, for example, we not only build a commercial version of Java, but we also build a pure open JDK-based Java distribution called Submachine. Other companies like Azure, they build Zulu VM from it. Amazon builds Coretto. Also, they just take the plain open JDK and build their binary distributions out of it and they all contribute under the Oracle Contribution Agreement. Okay, so just a quick overview of the Java versioning. So we had 678, but the update scheme was quite complex in the past. So we had 8 up to 20, 40, 60 for limited update releases, which introduced new features. Then we had critical patch updates, CPUs, which were odd numbered, like 8025, 31 and so on. And we even had patch set updates, which only contained the security fixes of our critical patch update because critical patch update could also contain non-security fixes. So with JAP-223, a new version scheme was introduced with Java 9. So we get 9, like before, 678, but then the update releases were the third number, like 901 was the first update release, but then the second update release was called 904. So why four? Because actually this third number denoted the months after the initial release. So first update actually means it was released the months after 9 was released and four was released, three months after 901 was released. So this was a little confusing. So with Java 10, again we got a slightly change in the versioning scheme. It was also adapted to the new time-based release. And we had, actually it looks pretty the same, but you may realize that now the first update is called 10.01, the second one 10.02 and so on. There was also a Java vendor version introduced. This is a system property and also a tag which vendors can use to denote their version numbers. So this was 18.3 for 10 and 18.9 for 11, you may guess, what is this? This is the year and the months. So actually this number comes from a very initial proposal of this JAP where there was a proposal to do it like this year, like Ubuntu this year and months, but nobody really liked it in the community, so we switched to the scheme we have now, but obviously Oracle liked it, so they somehow wanted to preserve it. But yes, and also we also added the notion of LTS. So the version string can also contain LTS if it's an LTS release. But in the end with this bug, they finally also want to get rid of it because nobody uses Java vendor version. For example, V4 submachine don't use it and other vendors as well. So it's now proposed to remove the Java vendor version from the version as again. So how does this look like when you, you have Oracle JDK on the top and the Open JDK on the lower end. If you run Java minus version, you see the first difference is that Oracle JDK, also it's built from exactly the same sources, but by Oracle and called Oracle JDK, they have the right to call it Java while the Open JDK builds and the GPL, they are just called Open JDK. Then we get the version and this is the vendor version, which is still in 4.11. And we get also the build numbers and the version of the runtime, which is usually the same like for the class library, which is the same like for the runtime. But isn't there something missing? This is Java 11, so LTS release. I'm not sure if Oracle was not sure if they should make an LTS out of 11. I suppose they just more than forget to add this string because then with 11, 1 and or 2, they added the LTS string to the release. While you can see that Open JDK has no LTS tag because as I told you, LTS, it's not an attribute of the Open JDK, it's vendor or implementer specific. So different vendors can decide to do LTS or not, but it's not tied to the Open JDK project, actually. So some words about the release model. Yes, we saw that before. We have releases every six months and updates a month after the first release and then every three months thereafter. Open JDK, so Oracle provides two of these updates for all the releases. So actually, by default, all releases are short-term releases in the Open JDK. Some vendors' version scheme is actually intended for enhancements, but it's not used currently. And Open JDK vulnerability group, which we, thankfully, have now, cares for and coordinates security fixes which go into the update releases. So a very quick overview of the various Open JDK distributions which we have. ICT from Reddit, it was the first, actually, Open JDK distribution. They built the first build harness which enabled it, which made it possible then 11, 12 years ago to build Open JDK sources with only free software. They are the base of Linux for Open JDK packages and most Linux distributions. And nowadays, they have a lot of extra features which are downpour to all the releases, for example, like Shenandoah, ICT web, and they also support new platforms, also, in older releases which also contribute upstream into the Open JDK, but, for example, R64 or Shenandoah is in Open JDK 12 or 13, but in Open JDK sources, A, it's not available, but the binary is built by Reddit. It's supported. And recently, I saw they also have a Windows version, so it was interesting for me, but yes. Then we have adopt Open JDK, Open J9. I put this on the same slide. As we adopt Open JDK, it's actually a community initiative which provides pre-built binaries and they support both hotspot VM and Open J9 VM, so Open J9 is a Java virtual machine from IBM which was open sourced in the Eclipse Open J9 project now and it can be combined with the Open JDK class library to create a Java JDK. They support a bunch of platforms and IBM offers support for Open J9-based adopt Open JDK binaries. I mentioned before we have Zulu Enterprise, Zulu Embedded. This Open JDK-based distribution from Zulu, they offer commercial support for it. They support versions from 6 to 8. They have this medium-term support. What I don't quite like is that they have like a private source model, so the sources are actually in the GPL, but they don't have public repositories. You can of course always request the source code of such a release, but you have to do it manually. Then we have Coretto from Amazon. They only have eight now, but they plan to provide 11 later this year. They also have LTS support. They have Open Github repo with some add-on and fixes. Liberica, another Open JDK-based distribution from Bellsoft. Also, you can buy commercial support from them if you want. Submachine, well, as you can see in my t-shirt, this is one of my babies. We also have Open Github repost. We have some add-on, down ports and fixes. We only support it for our customers, which have actually support contacts with SAP. They also get support from it. There is others like GraalVM, Jyx, Jakarta, JMVM. There's a very good list on Viki, so if you're interested in this, you can look there. Then we have commercial JDKs like Oracle JDK, IBM, SDK, Java, JVM, HP, Fujitsu also have a JDK. Excelsior Jet, it's a special JDK. It's commercial JDK which does ahead of time compilation. Jamaica VM, it's a real-time JVM. And yes, how do you actually choose your JDK? Well, of course you have to see which Java version is supported. You should look for a platform support, especially if you want to support all the Linux systems, for example, with all the kernels or GDPC. You have to be very careful because not all these distributions run on all the Linux versions. You have to look at the support and support time frames, see if it's free or paid. And of course you should look how your render is involved in the Open JDK process. This is the same slide presented by Mark before. So obviously somebody who is involved in the Open JDK project could be trusted more than somebody who does everything on his own. So in the end I would say Java or Open JDK is alive and kicking. You have the choice which distribution to use with OpenJ9.io even have a great alternative VM now. Competition is good. Collaboration is good as well, maybe even better. And I don't like the proprietary JDK and I think it will become dispensable because the Java platform is quite major now. Everybody uses the Open JDK class library anyway and if you don't have the possibility to speak about these things it won't be important anymore. So that's all my slides are available here. Thanks for listening.