 And with no further ado because I am fully aware that you are not here to listen to me blather. I would like to welcome Mark Reinhold, who is the chief architect of the Java platform group. See, I got it right this year. Who's going to tell us about the state of OpenJDK, which these days basically means the state of Java. OpenJDK is Java. Thank you, Andrew. All right, first things first, can everyone hear me? Back of the room. Awake, hello? Good morning. Oh, excellent. Okay. So, you might think that the title of this talk is the state of OpenJDK, but that's not true. This will be about the state of OpenJDK, the state of Java, but it's actually two talks for the price of one. Or one and a half talks for the price of one squeezed into 40 minutes. I'm confident that Andrew will kick me off the stage if I run over, so I will endeavor not to run over. So, two talks here. The first one is, modern Java changes the only constant. In the past couple of years, we've changed the Java platform in three ways that we never have before. First, we took this massive monolithic thing that had grown monotonically over time and we sliced it up into 26 standard modules. Second, we removed the Java EE and Corba modules and some other APIs, leaving us with 19 standard modules. And third, we left behind our historically grand and majestic but slow-moving and unpredictable release model in which we shipped a major release every two to five years, whatever, and replaced it with a rapid cadence release model in which we ship a feature release every six months on a strict time-based schedule. Now, modularizing the platform and removing some modules did break a few things and many have wondered whether the Java ecosystem will be able to keep up with a six-month cadence. Taken together, all these changes are frankly somewhat scary, but they're maybe not as scary as you think. Why did we make them? Because to adapt or perish now as ever is nature's inexorable imperative, according to HG Wells. Or if you prefer a more modern formulation, adapt or die. So say at Andy Grove. We must change Java in new ways because its competitive environment is very different than it was 20 years ago. There have been two big, broad changes. The first is that many popular platforms now ship new features around once a year, if not every six months. If Java's to remain competitive, we must move it forward faster. The second is that applications are packaged and deployed in different ways than they were 20 years ago, whether to the cloud or in packaged apps to app stores. If Java's to remain competitive, we must adapt it to these new environments. Let's look briefly at the first big change, modularizing the platform. This massive change was painful, but it brought many benefits. One benefit is that the platform is now more flexible. If an application needs just a couple of modules, then you can link a custom runtime system that includes just those modules plus any other modules that they depend upon. This results in smaller docker images, smaller app store packages that are tens of megabytes rather than hundreds. To do this, take advantage of this. You don't need to modularize your app. You can just be playing old jar files the way you're used to. You can do that if you want, but you don't have to. Another benefit of the modular platform is that it's more secure since it can enforce the strong encapsulation of module internals. Of the six high-impact zero-day vulnerabilities reported against Java since JDK 7 in 2011, three of them would have been prevented if we had been able to strongly encapsulate the JDK's internal APIs. A final benefit of the modular platform is that it's easier to maintain. The JDK does have many internal APIs never meant to be used by external code. For decades, we've been warning people, don't use them. Don't do that. They've done that anyway, of course, sometimes in some disturbingly popular libraries. Now, to be fair, in some cases, developers were after critical functionality that they couldn't get anywhere else. So, okay, fair play. But at any rate, this has made the platform harder to maintain and evolve. With strong encapsulation, we can close off access to the internal APIs of the JDK simply by not exporting the packages that contain them. Now, if we did that right away, we would definitely break a lot of existing code. We're taking a more gradual, nuanced approach since migration takes time, especially in such a large ecosystem. So, starting with JDK 9 and at least through JDK 11, if your code uses JDK internal APIs, then it will not compile and it may generate warnings at runtime. In a future release, it will not run. To help you get ready for that future, when such code will not run, we introduced a new tool in JDK 9 called JDeps. If you run it with the JDK internals option on an existing jar file, it can detect most uses of internal APIs and often suggest standard replacements. I highly recommend that you use it. So, the modular platform enabled the second big change of the past year. We've reduced the platform by actually removing some things for the first time in Java's history. Well, the first time on purpose. We removed the Java EE and Corba modules in Java 11. Poof, they're gone. These were costly to maintain. They were the source of multiple security vulnerabilities over the years. And nowadays, they're either available elsewhere in the case of Java EE, or they're just, well, not that relevant to Corba. We removed some other smaller things too in order to modularize the platform cleanly. We removed some really obscure methods in Java 9. Most of these probably never should have existed in the first place. And we only did this after analyzing a bunch of existing code. Oops, sorry. To see if anyone was using them, which hardly anyone was. While we're at it, we also removed a pointless constructor that snuck into Java 8, Brian. We removed more methods in Java 10. All these were ill-defined, actively harmful, don't work, or never did anything useful anyway, so they're gone. We removed more such methods in one class in 11. Now, removing things can cause breakage. To ease the pain, we always give it advance notice by deprecating APIs to be removed, at least one release in advance, if not more. As an example of that advance notice, here are all the APIs deprecated in Java 11 for removal in the future release. A bunch of these are finalized methods we finally are getting away from finalization, a fundamentally broken mechanism. When an API is deprecated for removal, that's always noted in the API's Java doc, deprecated for removal will usually tell you why. And if you compile source code that uses an API that's deprecated for removal, then the compiler will helpfully warn you about it. So, popping up. First, we modularized the platform, then we trimmed it down, and then we started moving it forward at a faster pace with the new release every six months. How does this work? Let's look at the timeline. We shipped JDK 9 in September 2017, 10 just over a year ago, 11 last September, 12 is next month in about just six weeks, and so on, every six months, like clockwork. Now, a feature release can contain any kind of feature, language feature, library feature, VM feature, it can even contain a feature removal. For this to work, features or the removals can only go in when they're nearly finished. We can no longer slip a release in order to fix a broken feature. But that's okay because a feature misses the current release. The next one's just six months away, not three or five years or however many. At the beginning of all this, of course, was JDK 9, the final massive JDK release. These are all the JEPs that were in JDK 9. We shipped JDK 9 three years, six months after JDK 8, which had shipped in 2014. There were two major slips to the schedule. Aside from modularization, there are a whole bunch of other work here. Oracle engineers did do much of this work, but not all of it. There were six JEPs from outside Oracle by contributors from Red Hat, Leonardo and SAP, plus a couple of independents, Douglas and Laurent Borges. Amongst these non-Oracle contributions, we had three different CPU ports, some significant performance work, and an entire new 2D graphics rasterizer. So all that was excellent. Now, after all this, what was going to be in JDK 10? One worry we actually had was, well, a six-month release cadence, we might have zero features in a release. It's theoretically possible because, well, we're going to ship every six months like clockwork. But, ultimately, that turned out not to be the case. JDK 10 contained 12 JEPs, including one language feature, local variable type inference, more performance work, massive refactoring of the source code from multiple mercurial repositories into one mercurial repository and some other things. Now, again, Oracle did a lot of the work, but two JEPs came from other contributors. We had the garbage collector interface that we had at Red Hat and some Intel engineers enabled heap allocation on alternate memory devices. Right. Okay, Java 11 in September of last year, 17 JEPs, including some long-needed JVM improvements, new HTTP client API, the ability to launch single file source code programs, which is a pretty cool feature, and TLS 1.3, for the final internet standard. Again, Oracle did a lot of this work, but not all of it. There we go. Three JEPs were contributed by others. Some engineers from Bellsoft and Cavium improved ARM64 performance. Alexei Shepolev from Red Hat contributed the Epsilon GC, the GC that does as little as possible. Jean-Christophe Bailer from Google contributed low overhead heap profiling, which was actually a pretty big contribution for a first timer. Finally, that brings us to JDK 12. Still in development, not for much longer for delivery next month, there are eight JEPs in JDK 12, including a microbenchmark suite for the JDK itself, a preview language feature switch expressions, and various VM performance improvements. Most of these are from Oracle, but in JDK 12 we do have an entire new garbage collector, Shenandoah contributed by Christine Flood and Roman Kanky and Alexei Shepolev and whoever else from Red Hat and elsewhere who helped with it. So that's pretty cool. We're in the last weeks of JDK 12 development. Hopefully the first release candidate will be next week. Please test it out. You can get builds here. So if you think about this over time, as you can see what has changed isn't the rate of innovation, the rate of innovation delivery. In three years, by 2021 or so, we probably will have merged around 90 JEPs, just as we had in JDK 9. Now, these feature releases aren't just about JEPs, of course. Each contains many smaller enhancements and, of course, bug fixes as an example. Here are the issues resolved in JDK 11, almost 2,500 of them. Most of these were done by contributors working for Oracle, but there were significant contributions from SAP, Red Hat, Google, a few independent folks, Bellsoft, and a smattering of others. Okay, returning to our timeline. The six-month cadence will enable Java better to compete with other platforms, but you might be wondering, what about updates, security fixes, critical patches, what's going to happen with those? The plan in the open JDK community is to update the current feature release for at least six months. That's the GA release plus two quarterly update releases. And then every three years will declare a long-term support release. So the first one will be 11, which shipped this September. The next will be 17 in 2021. If you like, you can think of JDAA appear somewhere as the previous LTS. Each of these LTS releases will be updated well past the beginning of the next LTS release, and possibly even longer than that. Now, you might think that LTS releases are somehow experimental. There's just a fancy name for a beta. Whoops. Give it away, damn. But they're not. They are production-ready in every sense of the word. There we go. The only difference between an LTS and a non-LTS release is the support timeline. So now, as you saw glimpse of it, you have a choice to make. What is happening here? I think the batteries are drying. You take the blue pill or the red pill. You take the blue pill, you wake up in your bed, and you continue to develop and deploy on comfortable, conservatively managed, slow-moving LTS releases with an update release every quarter and a major migration every three years. You take the red pill. You go down the rabbit hole where you can enjoy the latest language features, API enhancements, performance improvements, and bug fixes with a minor regression every six months. It's up to you. All I offer is the truth. If you do choose the LTS path and take the blue pill, you might be wondering, who will produce your update releases? Again, you have a choice to make. Since JDK9, Oracle contributors in the OpenJDK community have focused and will continue to focus, primarily on feature releases rather than upon updates. Oracle will ship OpenJDK builds under the GPL license for the first six months of each feature release, GA plus two update releases, whether that releases LTS or not. After that, Oracle will offer long-term support builds, but in a change from the past, they will be available only under a commercial license that allows free use for development, but requires payment for use in production. That might sound scary, but don't worry. Java is still free. All of the code is still available under the GPL for anyone to build, test, publish, and update. Oracle engineers won't regularly contribute, much less lead the LTS releases as they have in the past, but that's okay. The OpenJDK community as a whole has a proven track record of transitioning the leadership of update releases from Oracle engineers to non-Oracle engineers. We did that for JDK 6, we did it for JDK 7, we did it again just yesterday. Andrew Haley of Red Hat is now the lead of the JDK updates project. We are already in the process of doing the same for JDK 11, where I suspect Andrew will add yet another task to his plate, at least for a while. So the LTS work will carry on in the OpenJDK community as it has in the past. You'll be able to get carefully built, well-tested JDK LTS builds from pretty much any Linux distribution, whether it's derived from Red Hat, Debian, Gen2, or Arch. And if you're not on Linux, you'll be able to get LTS builds from a variety of other providers. Now for this plan to work, it's critical that you be able to switch from one provider to another. In past releases, that wasn't possible because Oracle always held back a few so-called commercial features that were available only to paying customers. These included application class data sharing, Java flight recorder, Java mission control, and the Zed garbage collector. To enable such switching and to establish a level playing field over the past two years, Oracle has open sourced these commercial features. So the Oracle builds and OpenJDK builds are now functionally interchangeable. You can switch from one provider to another as you please. But when you choose a provider, consider those with the depth of knowledge that comes only from a long-term track record of investing in the platform. All right, you have a choice. You can take the blue pill or the red pill. You can choose the conservative LTS path and take the blue pill with a major migration every three years. That can be a good choice for a conventional enterprise-style deployment of a large application on a large server. Or you can choose the aggressive feature release path and take the red pill with a small migration every six months. That can be a good choice if you're deploying to the cloud or to an app store. If you choose the LTS path and take the blue pill, then you shouldn't ignore the non-LTS releases, some free advice. If you maintain an infrequently migrated system and you should still test it with each non-LTS release, so you can spread the migration pane out over time by the time the next LTS release comes out, you'll practically be ready to move to it. If, on the other hand, you choose the adventurous feature release path and take the red pill, then you can upgrade to each feature release as it becomes available and make sure that your tools and dependencies can keep up. Many will be able to, but a few won't, especially if they are no longer maintained. To sum up, we're evolving the platform at a more rapid pace in order to keep up with competing platforms. We have broken a few things, and we will continue to do so in order to make Java a better fit for modern applications. Are these changes really all that scary? Yeah, for four reasons. One is that we'll always give advance notice before removing anything from standard API. We'll only do so when there's a really good reason because we don't want to break existing code unnecessarily. Compatibility remains one of the core values of the Java platform. Second, you have a choice to make, which you didn't have before. You can take the blue pill and migrate every three years when you want to. You can take the red pill and enjoy the latest features and fixes every six months. Third, it's true that Oracle will no longer provide free long-term JDK updates, but Java is still free. Free updates will be available from a variety of providers, including all of the major Linux distributions. If you want active support, then you're probably going to have to pay someone for that or else do it yourself. But that's always in the case. So choose your provider wisely. Finally, we did break a few things. Migrating past Java 8 may require some work, but it might not be as hard as you think. All three of the major IDs already support most of the new language features. Many popular tools, libraries, and frameworks already support JDK 9, if not JDK 11, and you don't have to take my word for it. As you may recall from last year, after Java 9 was released, I asked on Twitter, do you maintain a popular Java library, framework, or tool if it works fine on JDK 9? Then please reply with its name and version. That was a year ago. So shortly after JDK 11 was released, I asked, do you maintain a popular Java library framework or tool if it works like heaven on JDK 11? Then please reply with its name and version thanks to Sam Brannon of the JUnit team for that hashtag. It's gotten many responses to these queries. All 93 of these libraries, frameworks, and tools work just fine on JDK 9. In many cases, they work without change. In some cases, they had to make minor changes. All the build tools are in here. Maven, Ant and Gradle, test frameworks, JUnit, TestNG, popular libraries, BiteBuddy, Jackson, Log4J, Hibernate, Juke, Netty, and the entire Spring framework. That's a lot of code. 51 of these components work not just fine on JDK 9, but like heaven on JDK 11. Since the transition from 9 to 11 is much easier than the transition from 8 to 9, I expect the rest of them will catch up in short order. My most urgent advice to you today then is this. If you're using Java 9 or later, upgrade to the latest versions of all your tools and dependencies because everything changes and nothing stands still. That's the end of the first talk. Okay, halfway there. Only 25 seconds over. Let's see what we can do. Thank you. Okay, as promised, let's now turn to the second topic today. The future of Java and the JDK. What is the future of the Java platform and the JDK? What is the technical roadmap, both short-term and long-term? These are questions that I'm often asked. Most importantly though, and sort of going up one metal level, who gets to decide what goes in to the technical roadmap? Who guides the development of the Java platform or perhaps most bluntly, who is in charge? As is so often the case, to answer a difficult question, it can help to look at the past. Java is almost 24 years old. That's middle age or maybe late middle age for a programming platform. Java has been declared dead on multiple occasions. It's been accused of being in, oh, it's just in deep maintenance mode. Oh, it's the cobalt of the 21st century. Which actually might not be such a bad thing because a lot of cobalt is still used these days, but never mind. Anyway, Java is still one of the most popular programming platforms in the world. Now, ranking programming platforms is a business that's fraught with difficulty, but one of the more believable rankings is from Redmond. This is their report from June of 2018, the most recent one. The way they do this is pretty interesting if you haven't seen it before. The x-axis is the popularity rank on GitHub and the y-axis is the popularity rank on Stack Overflow. So the higher the rank, the higher a language will be to the upper right-hand corner and there indeed is Java way up there on the right with some other language called JavaScript, is it? I'm not sure. Anyway, how did Java attain this status and what should we do to keep it there? What's the secret? Is there a secret sauce here? Well, yeah, there is. The secret is that we've always taken the time to think about the big picture and the long-term. As developers, that is, people who create things, we also try to act as stewards. That is, we try to be responsible for overseeing and protecting something considered worth caring for and preserving. We try to preserve the past while evolving for the future. A steward in this sense is a developer who's not only interested in writing code and designing new features, but one who has also demonstrated a lot of things. One is deep knowledge in at least one area. A second is a breadth of care across the entire platform. To really think like a steward, you need to think from time to time about the entire platform, how the whole thing fits together, even if you don't understand every part in complete depth. Finally, and this is a skill that is frankly tough for a lot of people in our line of work, but it's not a result of empathy. To act like a steward, you need to be able to put yourself in the mind of an ordinary developer who uses the platform rather than works on the platform. In many cases, that's a very different kind of mindset. Our stewardship of the Java platform has always been guided by two key values, readability and compatibility. Graham Hamilton elucidated these values well back in 2005 about readability he made three main points. Reading is more important than writing. Simplicity matters. And Java is meant to be one language with the same meaning everywhere. Why is readability so important? Well, readability is essential to maintainability. Java has never been about write once throwaway code. It's been about building large reliable programs that can be maintained over a long period of time. A more condensed statement of this idea that I've always liked is due to the assessment of MIT. Programs are meant to be read by humans and only incidentally for computers to execute. Hamilton also discussed compatibility with respect to evolution. We will evolve the Java language but cautiously, with a long-term view, we will add a few selected features periodically. We want Java to be around in 2030, 2040, 2050. He was speaking here of the language but these values apply equally well, of course, to the entire platform. There are several aspects of readability. There are several aspects of compatibility. There's the familiar trio of source, binary, and behavioral compatibility. Most of us know what these mean. Source means existing code continues to compile. Binary means existing code continues to link at runtime. Behavioral means existing APIs continue to behave the way they used to or at least within the bounds of their specifications. There are at least two other kinds of compatibility that are critical to the success of Java. Sorry. One is what's come to be called migration compatibility. I don't think this is the best term but it's the term that's kind of stuck. What this means is that you can adopt new features incrementally without flag days. You can do things piecemeal without migrating all of the code you use to a new feature in one shot. We first pulled this trick with generics and we did it again with lambdas and again with modules. This is a good trick. There's another kind of compatibility, perhaps the most important one of all which I will call intellectual compatibility. Intellectual compatibility means that new features build on existing knowledge rather than destroy it. Millions of developers have spent countless hours learning the Java platform. We don't want to throw all of those hours away as the platform evolves. To preserve that investment we must carefully balance conservation and innovation. We must respect the past but not be unduly constrained by it. We will add selected new features over time but we must strive to make them look like they've been there all along. This is a constant balancing act. Most of all, we must have the guts to say no. To follow some of the best advice ever from James Gosling we must have the courage to do no thing rather than the wrong thing. So readability, compatibility preserving these values while moving the platform forward is much, much much harder than it looks. Many developers don't really care for this type of work and so we draw the distinction between developers and stewards. Being a developer is fun. It's great. You get to build things sometimes even from scratch. It's great. I love writing code and that's probably what drew many of us in this room to this line of work in the first place. Working on Java itself can be even more rewarding because you're building something that's used every day by millions of developers around the world to write incredibly sophisticated complex systems yet some of us also find it incredibly rewarding also to act as stewards to think about the big picture and the long term working to balance conservation with innovation for the future. With this history in mind let's get back to the question. Who is in charge of the future of the Java platform that JDK? Is that future directed by the Java SE Expert Group in the Java community process? Excellent answer. No. It's not. The role of the Java SE Expert Group and of the JCP generally is not to innovate but rather to guard the integrity of the platform specification by ensuring that the reference implementation satisfies the specification and that the specification is independently implementable. This is a role of advice and consent much like the Senate in the United States government was well intended to operate with respect to the ratification of treaties in the appointment of certain officials. Anyway. Okay. If it's not the JCP is the future of the platform directed by Oracle, Red Hat, SAP, Google, Intel, IBM and other big companies meeting in a secret room somewhere. No. It's not. The open JDK community isn't about companies. It's about developers. The very first sentence of our founding document makes this plain. The open JDK community is an association of developers who collaborate upon open source implementations of present and future versions of the Java platform standard edition. Most developers who work in the open JDK community full time today are employed by a company and the majority of those are at the moment employed by Oracle. That does give Oracle the company a lot of indirect influence but it does not give Oracle the company direct control. Some other long-term developers are employed by other companies such as Red Hat, for example. And we'd be thrilled if yet more companies would step up to the plate and fund developers committed to working in the open JDK community for the long haul. Okay, so if the open JDK community is about developers rather than companies then is the future of the platform directed by all the committers in some purely democratic fashion? No, it's not. Recall the key distinction, developer versus steward. Not all developers are interested in acting as stewards. Some positively hate the idea and that's perfectly fine. Not everybody has to be a steward and well, if we had all chefs and no line cooks then nothing would ever get done anyway, right? So we need a good mix of the two. People who just want to be developers are totally welcome. They do essential and important work. Yet in this distinction rests the answer to our question who is in charge. The stewards are in charge. Who are these stewards? This mysterious group of people who chooses them, who leads them? Well, I do. The formal name for my role in the open JDK community is open JDK lead but maybe it should really be head steward. I've been working on the JDK for over 22 years now and in that time I've contributed a few things, large and small. In that time I've made some mistakes too, large and small. And I've seen plenty of other people make mistakes. I've seen the long-term consequences of many of those mistakes and tried to learn from those. I care deeply about the future of the platform and even after 22 years I've still find it a thrill to ship each new release and well, I get to do it every six months so it's great. I also for better or worse seem to have a higher tolerance than most people for defining and running processes that other developers are willing to put up with. This goes all the way back to my first days at Sun Microsystems when I was so frustrated by the really bad processes at the time that I decided to try to improve them so here I am. Now, it's impossible of course for any single person to steward the entire Java platform in the JDK. I am certainly not that smart. Java has grown into a rich language and platform. The JDK has grown into a large and complex system. So, I therefore rely upon in many cases delegate to other developers who also find some reward and even the occasional smidgen of joy in acting as stewards. Chief amongst those are John Rose for the Java virtual machine and Brian Getz for the language libraries. John, who couldn't be here today, he's one of the few people. In fact, I think he's the only person still around who's been here for longer than I have. We're both somewhat daft. Brian is a relative newcomer. He joined Oracle's Java team 12 years ago, but he had contributed to the platform prior to that. Many other contributors in the open JDK community help with stewardship as part of their day-to-day work to a greater or lesser extent. Many of you who do so are here in this room today. Some stewards don't work for Oracle, such as Andrew Haley of Red Hat. Some stewards don't even work for a company, such as Doug Lee of SUNY Oswego. Whoever they are, every one of them has a demonstrated long-term track record of deep expertise in one area combined with a breadth of care for the entire platform and the ability to empathize with ordinary developers. The future of the platform then is in the hands of the stewards who constantly strive to balance conservation and innovation so as to change Java's core values of readability and compatibility. How do we do that? There's no formal process for it, thankfully. Much of it involves quiet, solitary thinking, sometimes even for months or years between a tiny idea, a tiny idea is even suitable for discussion, germinates even suitable for discussion with someone else. Much of it involves informal personal interaction on phone calls, on video calls in conferences on mailing lists. Much of it happens within Oracle's walls and well, that's natural since many stewards work for Oracle but it's also a bug because it makes it harder for non-Oracle stewards to participate and that's a big reason why we've started to have these OpenJDK Committers Workshop meetings. We have the first one last August, we're having the next one this coming Monday nearby. The fruits of these discussions surface for all to see and further influence in two primary ways. One is as in new JEPs in the JEP process and the other for larger efforts is in the form of new OpenJDK projects which explore problem area in depth, sometimes for many years and eventually generate one or more JEPs that eventually wind up as features in a platform release. You'll be hearing about some of these projects later today. Now maintaining the technical roadmap and doing all the other jobs of a steward especially of the head steward inevitably involves making decisions. When I make a decision I consult with other stewards and reviewers and committers and try my best to build consensus amongst the parties involved if that's needed. If I'm party to a decision then I recuse myself and delegate to someone else. Sometimes I've been unable to find consensus and had to make a decision that left some people unhappy but fortunately that's been very rare. I encourage everyone in any kind of decision making role in the OpenJDK to act in a like manner. If you don't like a decision that someone makes then you're free to appeal it. If you don't like a decision that steward makes about the libraries you can appeal it to Brian. If you don't like a decision that Brian makes you can appeal it to me. What if you disagree with the decision that I make? I'm not a benevolent dictator. I mean I try to be benevolent but I'm not a dictator. I'm a benevolent dictator as some open source communities have or until recently used to have. If you really strongly violently disagree with the decision that I make and you can't convince me to change my mind then you're free to appeal it to the OpenJDK governing board. Since 2011 when the current bylaws were ratified no one has seen the need to make such an appeal. Now you might be wondering if you're not a steward maybe you don't even work on the JDK but how can you influence the future of the platform? Just as in any other healthy open source community the first rule is that you have to show up. Every one of you in this room, every participant every open JDK mailing list, every individual on the internet even whether employed by a large company or not has the opportunity to influence the direction of the platform. The degree of your influence is determined by the extent to which you show up and contribute in the OpenJDK community on a meaningful ongoing basis. So here are some examples. Good bug report that'll get you some influence. Many good bug reports will get you more. A constructive critique not just a drive-by shooting oh I don't like that but constructive critique will get you a small amount of influence many such critiques will get you more. A bug fix that's good. Many bug fixes are better. Do you see the powder here? A small enhancement? That's really good. Many small enhancements are better. An entire non-trivial JEP, that's impressive. Many such JEPs are even more impressive. As you can see, what's important isn't just the quality and impact of any single point contribution but the ongoing commitment over time has demonstrated by your actions, not your words to improve the Java platform and the JDK. Your actions need motivations of course and I don't expect anyone to act out of charity. But if you only participate in order to serve you or your employer's narrow self-interest then you're unlikely to gain much influence. If you only show up to play political games, blocking progress and wasting the time of other contributors in order to make you or your employer look good then you will have no influence at all. If you show up only to participate in bike shed discussions of language syntax then you'll have a little bit of influence but frankly not that much. If you show up with just a few narrowly focused patches that reduce your own technical debt but aren't of much value to anyone else then you're welcome and you'll have a little influence but again not that much. But if you develop a strong track record of consistent serious contributions over a long period of time then your influence will grow quite large. You might even become a steward someday so be careful. But that will happen only if you or your employer see that your self-interest is best served by contributing in ways that are not obviously to your short term benefit but will keep Java itself vibrant for the long term. The future of the platform is in the hands of the stewards. Anyone else can influence the future of the platform in proportion to the degree to which they show up and contribute both in the short term but for the long haul. Is this all the way it should be? Maybe, maybe not. But history shows that it's worked very well for quite a while now. By taking stewardship seriously we've managed during Java's 24 years so far to evolve the platform in ways both large and small while preserving its core values of readability and compatibility. When you look back and think about it adding generics, lambdas and modules without syncing the platform were pretty impressive feats. Why did these take so long? Was it just stubborn obstruction? Shouldn't these have been relatively straightforward? I mean other languages have these. The answer is that to add them we had to have the guts to take the time to iterate over and over and over to get them right, to make them fit to preserve readability and compatibility and that's what we will keep doing to move Java forward. Don't believe a word I've said. Thank you very much. 22 seconds over. Sorry.