Life After Java 8

Transcript

This is a talk that has a few different titles. We've been kicking it around for a while. one way is to look at this, look at all the cool features in Java. Another one is from JDK 9 to 13 and beyond, and all this stuff. I like to call this Java After 8. This is the world After 8. All of you are on 8. Virtually, all of you said you're on 8. There are a few that are using pre-8 and like we said, we feel your pain. This is about what is after Java 8, going forward, what you should be looking forward to, what you should expect, what's coming. I'll cover a few different things. I'm just picking a few features here and there to highlight in logic of change, but also talk about what it actually means to go into production after 8, what people have done, what people might be doing going forward, what the actual considerations might look like because there are all kinds of things with this pace change that matter.

Bear with me as I go through features. Eventually, I'm going to get through some actual what can you do to take it to production and what we think the right roadmaps look like.

Changes

We've got a bunch of changes that have gone with Java. We have Java 6, that's now 13 years ago, and some people here are using it. Java 7 came out a little over eight years ago so it's long in the tooth too. Java 8 is only about five-and-a-half years old. It seems like it's longer than that. The really cool thing in my opinion in 8 is it really took over the world very quickly because it had probably the coolest developer led featured drive in Java since probably Java 5 with generics or util.concurrent, those two drove them. I would say even more than those.

Lambda expressions, people just liked coding that and Java 6 had some features. In Java 7, you could save a little bit on the curlies and brackets, but 8 was very material. It changed how we code. Great. After 8, it took a while, and then we got 9. Then we got 10, and 11, and 12, and 13, and we're going to get 14. We're almost at the halfway point between 13 and 14. It's going pretty quick.

You guys probably all know this and have heard many, many different talks about, that this will be just a little bit of perspective on it. The good news is it seems to be going on track on the declared path, exactly on the declared dates, which I really like seeing. Things aren't coming out on the date that they were planning to come out two years ahead of time. I mean, they're not ahead of time, the declaration was two years before and it happened.

Also, heads are spinning. You guys are still in 8, and a quarter of you have actually gone to 11 but very few are only on 11. You're still in the 8 to 11 move and 11's already been the past, sort of, maybe.

Java Version Timeline

If we look at it from a math perspective, it looks like this. The long lines here, actually the Oracle declared long-term support releases, 7 and 8, and 6 before that, were long-term support, 11 is long-term support. This release will be around from Oracle and with community support from the community for quite a few years. It's going to stick around like Java 8 stuck around. As I said before, 9 and 10 are dead. They were six months and gone. Nobody is releasing an update to Java 9 after 9.04 or to 10 after 10.02. There is no 10.03. Don't expect it, it'll never come. You can build your own and maybe put it out there, but none of the folks actually doing JDK seem to be doing that.

We all know that we're going to do 11. We're all supporting 8 for quite a while to come. We are here in this interesting desert. Between 11 and 17, 17 will be the next LTS. For those of you not tracking the numbers exactly, it's every three years, there'll be an LTS and it revs every six months. Every sixth number is an LTS. Assuming all 6 keeps like that, 17 and then 23, and do the math. All these other ones in the middle are feature releases, but they're full-blown Java releases. Revs of the class file version, all the parsers will break, that kind of that stuff. They have interesting stuff in them, but they live for six months, then you got to move, and there's no updates until you get to the next one.

In this interim thing, I predicted as a result of this, most of you are looking at moving to 11 and staying. Staying, running in production in 11, playing with other things, then move to 17 and staying. Some of you will actually race much faster than that. Some of you are in this world where you control everything. You have a lot of guts, and you will take your production on the latest thing that's two months old and run it in production. If there's a bug, you'll figure it out and you'll move forward or move backwards and change your code. Most stuff in the world doesn't live like that because most software in the world doesn't have a developer attached to it.

When you take that code and you move to your other job or to your other projects, somebody else has to run it. When the JVM version no longer updates, and you got to move to the new one, and it doesn't work on it, somebody needs to call a developer. I guess that's job safety fine. Say every six months is a little hard. This is actually a problem and I will come back to talk about it towards the end.

Coming up to Speed

Let's look at what we need to do to come up to speed. There are a few things here. First of all, the current Java is either Java 13 or 11, depending on whether you mean run in production long-term or the latest one that is out there is a GA version that can run today.

If we look at the changes, you got to look at the changes from whatever you're running right now until then. If you're running on Java 8, then you need to look at all these changes to figure out what 13 is. What happened in 9? What happened in 10, etc?

What I'm going to do is go over some of those. It's exhausting, you can't go over all of them. I'll cherry-pick a few but we're going to go through some samples of what happened in each one of those, some highlights of interesting stuff in them. Hopefully, that will be useful. If you really want to study this, you can study it in depth. My colleague, Simon Ritter, who actually helped me put a bunch of these together, does these really cool talks on 55 new things in Java 10. The cool thing is, that's like an hour of 55 things in Java 10 you can learn. If you have the time, there are recordings for various shows that he's done those. He's done those for 9, and 10, and 11, and 12, and now he's doing 13.

Changes

Changes happen in a few different areas. First one is to the Java language itself, changing how we write code, new syntax, "now you could write it this way." Then we have changes to the platform. When I say Java 13, I mean the language, Java, not Scala, not Clojure, not Kotlin Java. When we talk about the platform, we're talking about the JDK. That includes what Scala, and Clojure, and Kotlin, and Groovy all run on. There, we'll see JDK 13 or Java SE 13. There, we're changing the specified APIs, what's in the libraries, the behavior of the code, the platform itself, things like that, but the behavior in a way that you can sense functionally.

Then we have OpenJDK, which is a specific implementation of Java, an important implementation of Java because that's where Java is actually developed, and the new versions of Java are rolled out there. OpenJDK actually provides the reference implementation for the Java spec. When we nail down and say, "This is Java 14," there'll be an OpenJDK version that is the reference implementation for what that is. We'll vote that it really is. It will stay frozen, it's not the updates to that the reference implementation is frozen in time, but it comes out of OpenJDK so it's important.

OpenJDK has a bunch of cool under the hood stuff, implementation-specific stuff, that have nothing to do with Java the language, or Java the JDK, or the libraries, or the functional behaviors. They have to do with speed, behave things like garbage collection. Pauses are not, speed are not, sizes are not, how fast you start, how you compile, those don't change anything in your code. They don't change anything in your functional behavior. You can take your code anywhere, but hopefully, they're changing it for the better. You're getting faster, better, smaller pauses, larger heaps, whatever you need there. Those changes should not be confused with changes to the Java SE platform, which is a specification or to the language, which is a specific thing there. As I go through things, you'll see all these categories mentioned. Just keep in mind that they're not commingled. Change to OpenJDK's internal garbage collectors is not a change to the Java platform. We have people from IBM there with J 9. We do Zing, various things. Just because some implementation changed one thing doesn't mean the platform changed. We all still run the same code.

JDK 9

JDK 9 was probably the last really big platform change. Lots and lots of changes. Why was it the last? Because it was the first of the six-month version. After JDK 9, we moved to six-month cadence, only a few things change, then only a few things change. JDK 9 was a full shopping basket in two-and-a-half or actually three years, I think, of time between 8 and 9. Lots of things in there. I get one thing in there, on spin-wait is my fault, but lots and lots of cool, different changes. Probably the biggest one everybody's noticed is the Java Platform Module System. Fundamentally, the JDK itself became modularized under the new module system. The biggest beneficiary of the module system is the JDK itself. It's actually what drove the modulization. Yes, it's sort of thought of what you might do with modules. The reality is the JDK wanted to be modularized itself and most of the design is driven by it.

The JDK is now broken into 75 different modules. Here's some stats about them. Most of the internal APIs are now encapsulated. They're in a module. You can reach them if you lift the right lids off the modules. Modules provide a new layer of encapsulation and security or containing visibilities and such. You can open up the can the right way. There was a lot of interesting back and forth before JDK 9 was actually voted in as a standard with some open discussions about what it will do to the ecosystem. We actually saw a change. This is a place where you could see the community actually doing really good work, both in the OpenJDK world and open other communities, and in the JCP, which I'm under JCP SE.

We actually asked them to change the spec before we voted yes on it and open some things up, specifically around things like access to sun, as you can see. There's other flags and what would the default be, what would the warnings look like, things like that. I'm happy that that happened. It was actually a good example for everybody working together. I think the hotspot developer guys did a great job on both proposing something, and then listening to the community, and adjusting accordingly. JDK 9 actually had a big change around that.

Another cool feature that some of you might have heard of is jlink. It's there from 9. Almost everything I'm talking about is from 9 on. If you're running 13, that also applies. It's just 9 was the first place it happened. Jlink lets us basically take an application in the JDK and then combine only the modules that the application needs into a package and image that is a smaller footprint. Small footprints are good for various reasons. One of them is they're smaller. The other part is the notion that exposure is lower. If you don't need the code, it's not there. There's less attack surface. There's no less bug surface, whatever those are. if you look at how people use Alpine Linux, for example, it's usually not about footprint, it's about exposure. It's the same notion. Jlink lets you do that. How people use it or not, it's still early to tell because not a lot of people run 9 and 11 is young. It'll be interesting to see if people use this feature or not.

With JDK 9, a bunch of cleanups started because Java is 20 some years old and it's been carrying a lot of baggage. Whether you like it or not, and I'm on both sides of this argument, some of that baggage needed to go away. It's too costly to keep around. JDK 9 is the first version of Java where things are starting to go away that have always been around. Deprecated APIs were actually removed from the platform for the first time in the history of Java. Until now, they just got deprecated and deprecated, and you got warnings, and ignored them. Some of those things you've been ignoring for a decade are gone. They're gone. You can't use them anymore. You should have listened. In addition to just regular deprecated stuff, we've had this evolution of big things being removed. In Java 9, for the first time, the entire Java.se aggregator module was removed. I'll show you what that is in a second.

Then, it was hidden. You can bring it back with a flag. That's part of the debate we had back then. In Java 11, it is gone. You can't bring it back. You got to go find an alternative on Maven Central. This is the same module but without changing something, that code isn't running. JDK 10 and above will continue this work. This was not a one-time reduction or elimination. It was a policy change. From now on, things will start going away. You should watch your deprecations and you should watch them closely. More features will be removed in the future. It's not just APIs and stuff but, for example, the CMS garbage collection, we just heard today is probably gone in Java 14, if not in 14, probably by 15 and a few other things, so things are truly going away. Again, it's baggage, 25 years of weight to carry around with people that aren't around anymore to maintain it is something you got to clean up after.

Here's a statement about compatibility. That sounds good, clean applications that just depend on the Java.se shouldn't just work. Now, unfortunately, the world isn't as clean as this. The reason is, this is an absolutely correct statement but note the very careful spelling of Java.se. This refers to the module in JDK 9 that is spelled Java.se. There are tons of Java SE 8 things that are absolutely going away. Java.se lowercase doesn't mean Java SE the platform. Big parts of the Java SE platform are no longer part of the Java SE platform. As an example, all of these are no longer part of the Java SE platform.

Does anybody here use any of these? Does anybody here think they indirectly use any of these? Has anybody here used the base64 encoder or decoder? Has anybody here used the JSON parser? They use base64 encoders. Guess where they are? So there are alternatives. There are many other places to get Base64 encoders. This is not that it's broken, it'll never come back. It's just that you need a new version of a JSON parser that uses the base64 encoder that doesn't come from here or you need to bring the Java.se module from Maven Central to add to your application because it's gone from the platform. Things don't just work and that's the key thing. For those of you that have gone to 11, I assume you've run into these things. Here's the good news. As you saw here, people can get past this. Don't be afraid. Don't not do this. Please do this. We all need to eventually move to this stuff. Just be aware that it's not just a Java 6 to 7 or 7 to 8-like transition. After 8, there's a bigger deal to move on. You need to be a little more thoughtful and prepare for disappointment.

New version of Java may include breaking changes. Anything for removal will be deprecated first, so you will be told, you will be warned ahead of time, and the minimum is one release of warning. That sounded good when releases were three years apart. Releases are six months apart now. Things can go away in a year. From warning to it's gone, you have a year.

JDK 10

9 was a big sea change. On to 10, 10 has a few cool things in it. I'll highlight a couple. Java has var. Why? Because it's sexy. Every other language that's sexy has var so we should do that too. I mean, that's one reason, I guess. Fundamentally, you write less code and you infer from the other parts, the types that you don't have to spell out. Again, depending on your coding style, you may like it or not. The good news is you don't have to use it. I tend to not use it. I like to skip inferring in my brain. I like it to say what I say but it's good to have it there for various reasons.

A couple of examples are you can propagate through, so those are simple. You just propagate and infer from right to left but you can infer the type string in the loop because you have the type of the variable. You can infer an int, which I actually am annoyed at because it forces you to put an L on the lungs. Then you can do some other things. This is a good example practical of how it cleans up code. For example, if you have tried with resources blog, which you should if you're doing good management around, try blocks for IO stuff, for example, that looks like this, you can convert it to look like that and it's more readable. It's a little bit of cheating because we picked exactly the thing that will fit on the screen if it's var. Again, in an IDE, you usually have a little more room as well. I do think this cleans up the code. This is clearly more readable than the previous for what it does. There's goodness here.

Var is a reserved type and not a keyword. Why would you care? If you're really into languages, you care but let's get practical for what that means. You can write this. It's ok to have a variable call var. Why? Because it was ok yesterday and we didn't want to break everybody's code. Therefore, it's not a keyword. It's not ok to have a class called var, with lowercase var. It is ok to have a class called Var with uppercase Var. If you had a class call var, with lowercase v at the beginning, you deserve this. Yes, it was legal yesterday, but come on. Var is here. Now you know what it means. Hopefully, you knew before.

Here are a few JEPs. JEPs are Java enhancement proposals technically from the OpenJDK process, not for the JCP but the OpenJDK process. You will see JEPs for everything from new language features, new platform features or just new OpenJDK internal features. All of those have a JEP. As you can see here, we have the JEP for the local variable type is up there. That's an actual language change. You write differently. We have powerful GC for G1, that's an under the hood thing, make G1 better. Application class data sharing, that's a start-up faster if we do the right things. Then experimental JIT and Heap allocation, and all these other things are under the hood.

They're good things. Thread-local handshakes are great building blocks for future concurrent collection and maybe cool, less hurtful deoptimizations and things like that. We've had a similar feature in Zing for a decade now called checkpoints. It's just a name difference, but it's a very useful thing, trust me. These are some selected JEPs from there.

There are also a whole bunch of new APIs so don't think that it's just a tiny little thing. Like I said, there's the 55 things in Java 10 you can look at. Here are some of the new APIs. You can do copyOfs and collections, which is very convenient, especially when you start looking at how you build, or do static initialized stuff, or just the shorter handwriting for things.

You can do unmodifiable, basically collections and stuff. Those are useful, not just for semantic of a care. I don't want to touch them. Potentially if you do this, you will get performance. Under various things over time, the JIT compilers could understand things like this collection is not modifiable and therefore act on it, and do better things with it. We also have things like, or else throw on optional. Anyway, a bunch of cool new APIs.

JDK 11

Onto JDK 11. Again, this is cherry-picking. It's not the whole thing. We have more cool things we could do with local variable. For example, if you have something that's written like this, you could change it to be like that. You could put a var on that S. You look at this and say, "Why would I do that? That's actually more text." The reason you would do that is so you could do this. If you don't want to start annotating things in lambdas, you got to put a declaration on them, instead of putting the type declaration full there and then getting very expanded declarations, you could just use var. I actually think, for me, this is where I would use var. Everywhere else, I would probably just spill the damn thing. Here, in order to be able to annotate the parameter through a lambda, I think this is a very useful way to do this. In lambdas, they tend to not type out the type, but I do want an annotation. To me, this turns it into a much more widely used feature from a language perspective.

Another cool feature that I don't know how many of you know of is we can now launch Java from a single source file, not just from an object, not just from a class. For example, you can say Java, something not Java, give it parameters, and it will run that. Yu could look at it and say, "Ok. Cool. I can write a little demo. I can give people source code and they can run it without compiling it." What is it really useful? We can now do this. This is a shell script with Java source code in it. This works. How many of you didn't know that? See, you learned. Here's your takeaway for today. You learned that you can now write Java shell scripts as of Java 11. You got to move to 11 – motivation there.

Here are a few other things about Java 11. Nest-based access control. This is one of those things that has been driving the JDK guys crazy and the Java compiler guys crazy, and the verifier guys crazy, but you don't care about. It has to do with how we had to deal with nested things that spread across class files that were actually nested in a source file with access control. It does do a great job of cleaning up the stuff under the hood. Again, it's very under the hood. It's under the hood specification-wise though. It's not under hood just for specific OpenJDK. This is a platform thing. Dynamic class-file constants are similarly a spec thing. They, again, probably don't show up in the code you use, but very convenient for the people who produce byte codes, produce class files. Lets us do things much more shortly, much more precisely, and probably because of how it's written, it'll tend to have people declaring things in a way that JIT compilers could blow through better for optimization. I really like it.

Again, under the hood specification, Java SE platform changed. That probably doesn't change anything you do. HTTP client, that's a big deal. Could you believe that we waited until JDK 11 to get an HTTP client in Java? It's actually a testament to how strong the ecosystem is because everybody's had an HTTP client in Java. We just had the problem of choosing which one. Now there's one in the platform, so hopefully, we'll end up consolidating everything on it so we don't have as many choices.

TLS 1.3 is actually probably the number one feature I've seen that drives people to Java 11 because they need it, not because they like coding that way. TLS 1.3 is about a year-and-a-half old, I guess. It's getting adopted widely and both for simplicity and some speed, but probably for security over time, it's going to become a driving factor, and 11 has it. It's the first version of Java that has it. If you need a functional reason to move to 11 because the world is pushing you there, this is probably it. ZGC is a new experimental low latency GC. I explained yesterday what experimental means in one of my talks, and hopefully, you heard. Then we have the Epsilon garbage collector, which is really cool. This is the don't do garbage collection, garbage collection. It was initially motivated by wanting to measure the overhead of garbage collection, meaning, don't do it. Then let's do it, and we'll measure the difference. Now we know how much it cost.

It turns out that some people actually use this. There's some people in the world that write zero GC code or very low GC code and are willing to run for a day with a large heap and don't want a single GC, and they're ok blowing up rather than GC. Epsilon is perfect for that. This is the run until you're out of heap and blow up GC. It's in there. You could turn it on. It is very useful for measuring with short-lived things, the overhead of various GCs because you compare Epsilon GC with other GCs on performance, and you've got your delta of how much you're paying for having that GC on. It's a baseline of zero.

New APIs. We have some new I/O methods, interesting null methods and for streams, these become useful later. I'll show you where is later. Having being able to have null streams both for input and output is useful when you combine things together, and optional is empty, which is the dual of is present. It's weird that we had one without the other. The duality is fixed.

Some new string APIs. This strip one is interesting because a lot of people look at this and say, "But we already had that." It turns out we already had it for some languages, meaning some like English. This is an actual true internationalization whitespace recognition stripping. It's a more correct way of stripping in a string, useful. String repeat. Say this five times. Yes, it comes in handy in some things. I've actually used it. I used to look, scoff at this and say, "What do we need this for?" Then a week later, I used it, so I guess it's useful.

This is a cool one. Predicate has a not method now, which is not predicate. You think of, "How do you use that?" Imagine you have this written and you can say, "Ok. That probably is readable, but it's readable. It's got a bang, instead of not." Some people don't think of that as readable. You also have a full expression here. You write the whole SRO thing just to say that it's not. With not, you could say this, which is more clean. You're saying it's not of that is blank. If you use import static, you can make it this. This is just more readable. If you're actually trying to say this is the not that without carrying the S through. That's nice to see the evolution of small API s in this case, that you write cleaner code, without changing the language. It just allows you to do the common expression in a more readable way.

Remember I said these are removed, removed. Up to now, these were hidden but in 11, they're gone. There's no flag to bring them back. This is the, I didn't mean it flag that we had in 9 and 10, now it's gone. The good news is, all of these are in Maven Central. If you need them, you can bring them back. You just have to change your dependencies and all those. The namespace is the same so you don't have to change the code that uses them, but you do have to change something in order to build a working environment.

JDK 12

12 has a cool thing called switch expressions. It also introduces a much larger cool thing or scary thing, depending on where you are, called preview feature. The way preview features work is these are additions to the language that we're not sure are going to stick around. They're "warning, warning, if you use this, your code might not work on the same version" and the next version might not even compile. To be able to run with them, you have to run with --enable-preview flag. If you don't do this, it'll say, "No." Won't compile, won't run. That keeps you honest. You're using a preview feature. You have to have the preview flag. It's like an experimental feature.

It's useful to try new things and then see how they are, and maybe you can change them. Like, maybe the spelling isn't exactly right, so you change them over time, and you're allowed to as long as it's preview stuff. Once you take out the preview thing, it's in the spec, and it's going to stick around for a long time, until somebody deprecates it. I don't think we've ever deprecated anything from the language. We've only deprecated APIs. Deprecating a language syntax would be terrible, a big thing.

Up to now, switch constructs were statements. You guys, hopefully, all know all the how to write switch statements. I'll show you an example. They're clunky. They're the old C style switch statements and they look like this. You have the different parts of the switch. You have to remember to put a break everywhere because the default is fall through. A fall through is really useful, like in the Monday, Friday thing. If you miss one, you get really surprising behaviors. You're going to either break or return somehow. There's a default. If you don't remember to do the default, you might actually be surprised at the outcome as well. Anyway, that's what a switch statement is. A switch expression, see that this is a switch range that is setting num letters to something right. It's actually a common thing to see is a pattern. Switch expression lets us write this. We want num letters to be this thing and it's a switch on the value that would be assigned to num letters. It's a right-hand side statement or a right-hand side expression at this point.

Nice succinct writing with lambda like syntax and that stuff. This is a nice clean translation of the previous one, probably more readable, more concise, harder to get wrong, that kind of stuff. Do the annoying bugs that the missing break in the switch. It's one of those annoying bugs that when it happens, you think you don't do it, but when you do it, it'll take you two days to find it. It's like you had an If with two lines indented, then you forgot the brackets. That's why I always put brackets on If's, because I've been burned, and why I can't read Python.

The new style switch statement is like a new old style. What if you want the old style but you want a statement, like an expression? You could do a break with a value and that becomes the value that's assigned to the left-hand side. That's new syntax.

Then you can do even bigger things with code blocks and they look like this. Again, lambda like syntax, where at the end of the block, you have your break with the value and that's effecting the return value from the block. That becomes the left-hand side assignment. Other JEPs, Shenandoah GC, another experimental concurrent compacting collector is now included in JDK 12. G1 has a bunch of nice updates that make it better. These are two under the hood things in the JDK. Remember no change to language or specs. JVM constant API and default CDS archive. CDS is a really cool feature. Actually, I would highly recommend people look at CDS in general. App CDS and CDS are very useful for startups, making startups faster, not paying all that class load and verification time every time you startup. If you're starting to do containers that come and go quickly and all that, you could shave a good fraction of a second off your startup time by doing this.

Another thing is streams now have these teeing functions. You could do the teeing and stuff into a buy function. This actually is where you fall into interesting cases. Remember those null streams we had before? When you want to tee things, sometimes you want to tee a null. I know it sounds weird, but you have a tee and you need to provide stuff, and you only have one, so give it a null for the other one. This is where that null stream from before becomes very useful.

This is an example of using teeing to do a very complicated way of deducing an average. It is actually a wave deducing an average. If you only have this many numbers, that seems like a complicated way to deduce an average. Why would you write it this way? If you had a million of them, ok, maybe not so much. Remember that streams can be parallel. This lets you do parallelized computation on an average and a collection, which is not something you want to write by hand. when you're wondering why write the complicated highly abstract wave, this lets you paralyze it.

JDK 13

JDK 13. We have this. Again, why? Because all the other languages do. This is very useful. It's for anybody who's ever written a bunch of these slacks and all that, and aligned them, whether it's for HTML or for other reasons. I'm very happy to see this. This is still being worked on what the final spelling here is. Is this exactly right? Is the imitation quite real? This is highly useful as it is, I think. Note that the indentation is deduced. Basically, what you have there is the output of that, which is the intuitive good interpretation. What the offsets are based on where you start them and all that. I have heard interesting corner cases where people have found and maybe want to change the way it's specified, but it's in there, you can play with it, and they'll probably evolve slightly.

Switch expressions. Remember we talked about this? Remember, I warned you what a preview feature is. Switch expressions written like this from Java 12, no longer work in Java 13 because that break has changed to yield. It was put out there, people gave feedback. It was confusing to see a break with a number or whatever other reason, I don't really know. Now the syntax is different. Break with a number no longer works. That was an experiment. "Nope. Take it back. Thank you for playing. It's evolved." This is the new way to write yielding values. This stuff is still spelled the same way. This simple, straightforward one is stuck around, but the way you spell the weird ones is changing. When this stops being a preview, That's really the syntax. You just learned the lesson about what preview really is because it changes. I half think that they did that on purpose because it's one thing to say, "We'll do this but we could change it," but doing it and changing it six months later, that wakes people up. Now you know how to really treat it.

It doesn't require the precautional warning it was previewed to begin with. Selected other chips, which are clusters. We talked about text blocks. We talked about dynamic CDS, archives, even cooler CDS. The ZGC has new uncommits, which basically means it can go elastic up and down. It could reduce the heap, not just grow it over time, which seems to be interesting in some environments where you have a lot of idle things sitting around. Then the legacy socket API has been reimplemented pretty dramatically under the hood, hopefully with both performance but also some robustness around corners that have been hurting people over time. That was 13.

OpenJDK

I went through a bunch of features. Now, I want to go from the features to, what does it really mean to use them? You guys are all still on 8. I'll give you a map of what might be fun here, but how do you go forward and how do you go forward beyond this? OpenJDK is great. OpenJDK is where all the source code for the JDK is developed. It's in the open, a lot of contribution and a lot of collaboration. Oracle certainly leads this with tons and tons of effort. We are seeing a lot of great community contribution and offers from there. You need to remember that OpenJDK is a source code project. The thing OpenJDK produces is source code. None of you run anything that's produced by OpenJDK directly. Every binary you have your hands on is a distro of OpenJDK. Think Linux kernel, Linux distro. Somebody put those together. Unless you're doing it yourself the way you like, I think no one of you does, then that's your own distro. Then you have a distro and it comes from somewhere. There are many of them out there, and some of them are well built and tested quite a few, but some of them not so much.

If you want an actual concrete example, this is a posting I wrote a few months ago on the JDK mailing list. Welcome to Google and find a very contentious discussion. I think the Debian community really hates me by now. Fundamentally, somewhere between April and May of this year, about 10 million people ran a JDK that said it's updated and it had security bugs in it that were fixed in the release it said it was but weren't in the build. That happened. Docker-run Java 8 did that. How many of you run Docker Java 8? You did that, from April to end of May. There was a CVSS 9 and two CVSS 8.1 fixes in that release. They were high severity and critical severity. They were not in the code even though the code said it had the version that matched OpenJDK thing. That is a bad build of OpenJDK.

Now, we had contentious debates. I think those people will do it right next time. What it means is, there are lots of options. It's up to you to choose which one. Here's a bunch of examples. There's others I didn't list here. It's up to you. You guys have a choice. Look around, check reputations, check history, make sure that it's a good one. There are various good ones, all these are free. Then there commercial ones. Obviously Oracle will have one, IBM will have one, Azul has commercial stuff as you can choose, so plenty of choice.

Since you have plenty of choice, let me talk about one of the choices, which is Zulu. Zulu has many forms. The main form of it is a 100% free, 100%, open-source, community distribution of OpenJDK. It's probably the longest, widest standing distribution of OpenJDK. We've got everything from 6, which we no longer update because it's old, but you can find Zulu 6, 7, 8, 9, 10, 11, 12, 13 and soon 14 EA.

We have every version of every one of those built-tested, TCK-d on a CDN for the last six years. That's what Zulu is and it's free. Go use it. It is a curated distribution. Virtually every distribution is curated. We take the pieces and all those. Think of it as we take all of OpenJDK as it is, and then we do things, like support different bitness that might or might not be supported by it, like, Java 11 and 32-bit, and doing ARM 64 and 32-bit, stuff like that. Also, some features that are not modifying the platform in any real way but have been convenient. For example, who here has played with Java Flight Recorder? A few of you. Who here have played with Java Flight Recorder and Java 8 in production? Who here have done that on a non-Oracle JDK? Why? Because JFR only was open-sourced in Java 11. Zulu 8 includes JFR. We backported Java 11 JFR to Zulu 8. There's an OpenJDK 8 with a free JFR in it. For those of you who like that, now you have it for free.

You have it for free in 11 from everybody. It is open-source part of 11 but we backported 8 too because, hey, a lot of people still use 8. Similarly, we provide a TLS 1.3 support in Zulu 8 with a flag. You turn a flag that says, enable open JSC and you get it backported with TLS from Java 11, available in Java 8. If all you wanted is TLS 1.3 and you still have a pain going through the other stuff, do this for now. I don't want you to not move to 11. Please do move to 11. For the things that have a hard time, this curated distro actually lets you do that. It's there.

We also do a whole bunch of different builds. We actually build over 800 different things every quarter because of all these combos. We have a JDK and we have a JRE. We also have a JRE with Java effects in it, OpenJFX. Who here uses OpenJFX? Who here thinks they might actually be dependent on OpenJFX? Here's an interesting story for you. The reason we have OpenJFX, JDK+OpenJFX is because the Oracle Java 8 has that. It turns out that because it was there and IDEs could see it, there's some classes in it that people end up using not thinking that there's Java effects because they were just in the JDK. You know what the most popular class is, the 80% case for people asking us for JFX? There's a pair class. It's 50 lines of code. It's a tupple. The JDK does not have a pair class, OpenJFX does. The most commonly used pair class in the Java world is the Java effects one. Now there's 50 other ones you can find on the internet, but you're using that one. We put an entire OpenJFX in the JDK just so your code will work for one class.

Yes, I got to say I'm pretty upset about that one, but hey. We thought of just packaging the pudding and putting one class in it because it's fat, but hey, the good news about this is it means there is a way to say, "The damn thing doesn't work. I don't have to change the code. Go get a distro that has the thing that says compatible as possible." The curated distro, in these cases, we're trying to make it as close as possible to move Oracle 8 to OpenJDK 8 without having to change your code.

MTS

Now on to the next part. MTS, midterm support is a concept that we've created. We initially had it only on the commercial side and we basically announced that this is now available for free for community for Java 13. Let me explain what MTS is and why it's needed.

Why do we need this MTS stuff? JDK versions need overlaps, in order to actually be able to use it in production. Here's an actual factual reason why. There are a lot of post GA bugs that happen. Thank you to all you guys that have done Java 11 early because you're making it better for the rest of the people. In Java 8, there were this many bugs fixed after GA in the first 17 months. More importantly, in the 12 months after the first 6 months, remember, all these things stop after 6 months, and 6 months after, there were 1,200 bugs fixed in Java 8. They don't stop coming. They start coming when you start using stuff. We're just now seeing the real adoption of 11.

Production use remains in some previous version and we need updates, bug fixes, security fixes for what we're running at production. We need them to happen at the same time. We need overlap. This is what overlap used to look like. We used to have years of overlap when Java 5 and 6, and 6 and 7, and 7 and 8. Then 8 to 11, we went down to four months, but now we're at zero. When Java 13.02 comes out in January, that will be the last Java 13 under current plans. If you use it, then the next thing to move to is Java 14.0 or 14.01. The first one will be a day old, the next one will be three weeks old. If you're stuck with something that doesn't work on one, works and the other but this one it's not stable, you're in a corner that's really hard to get out of, and good luck convincing your production people let you run that. Which is why we think most people under the current plan will end up playing, and waiting, and really liking that switch statement.

You can code to it on your laptop, but don't put in any real code unless you plan to deploy in 17. Probably a year into 17 after it's solid because look at how long it's taking people to get 11. We want to fix that. The way to fix that is with what we call midterm support releases. Midterm support releases, under our plan for community, and Java 13 is the first midterm support release we're going to do with Zulu. Allow you to keep running, will have updates, not for eight years but for 18 months after the next LTS comes out. They will have enough overlap for a soft landing into an LTS than the last four years. You can code the Java 13 today, knowing that there's a free way to deploy it and run it in production until there is a stable Java 17 you can move to. That's the entire purpose of MTS.

We've talked to people on and off about the need. We've gotten a lot of customer input for the need, basically saying we can't use this stuff unless we have a path forward. I think in the last month, we've announced that we're just going to do this for the community. We're hoping to do this as part of OpenJDK 13 updates, in OpenJDK projects. Regardless of whether the community does this together or not, Azul is doing it because we're doing it anyway. We've got contractual commitments to do it to customers, so we may as well do it as a free community thing as well. That's the interesting news about Java going forward. Java 13 is something you can use forever. There's those feature preview things, be careful. You can use it and you can write it into an overlap. You can move to Java 17 if that's the step you want to take. We will do the same for Java 15.

Notice how Java 15's length is shorter than 13 because its goal is 18-month overlap with an LTS. That's out there. Hopefully, you guys will get to use it and hopefully, that makes you like Zulu. Zulu Enterprise is basically the classic, here's the free cool thing. I told you what it is. Here's some commercial good support for it if you want to pay for that stuff and you like us. We do release these both MTS and LTS's. We do them fit for long-term production use. We take care of things like separate security on updates and separate bug fixes that are not security. So if there's an urgent security thing, you can deploy security on the update and not have to take the 130 other goodies with it. We have all the indemnification on contamination and we're very widely used across multiple industries.

Here's a few samples, just to give you a power fuel of that. It's not a tiny thing. Lots of people run their businesses on it. This runs on it. All of this runs on it, both internally and all customers. For 7, 8, 11 and 13, this also runs on it. Very often the silent choice under the hood that you don't even notice is using it. For example, who here has been playing with GitHub's actions? The new CI/CD thing in GitHub? It's in beta but coming out in the next few users, not beta. Take a look at it, but it defaults to use Zulu as the JDK. All the tests are done in Zulu. We do all these versions, we'll do the next ones. We'll do 24 by 7 support, etc.

For summary, Java is in good shape. It's been moving and we've had 8, 9, and 10, and 11, 12, 13, 14. We have the concept of LTS and it sits here and there, and there. Now we have this new concept of an MTS. That's what Java After 8 looks like.

See more presentations with transcripts