 Hey welcome everyone. Thank you for your dedication and staying here to the end of the day. Your reward for staying here so long is that you have to listen to us for a little while. So this is a little bit of a tradition. I actually had some slides but they're kind of boring so I'm not going to show them. You can imagine if you will a picture of a groundhog in case you don't know what a groundhog is. It's also called a prairie dog I think and and there's a tradition that on this day this little animal and it's a specific one crawls out of the ground and looks around and if it sees its shadow then there's going to be another six weeks of winter. So what's that? Well I don't know if it was in Brussels it probably did not which I guess is a good thing. It means winter is over you know Java will will thaw and continue to move ahead quickly so that's a good thing right. I'm not saying it was a good metaphor. There's also a movie which is sort of old and somewhat funny. So anyway what we it's like Groundhog Day because you know this happens every year and so this again is is a session that happens every year. We're always pleased to be back. Pleased to have Doug here with us. Hi Doug. And so generally what we do is try to just quickly introduce ourselves and then go and mostly try to have questions. So I'm George, George Saab. I am the chairperson of the governing board and I work at Oracle where I run the Java platform group and I've been working on Java since actually Mark and I started within a week of each other I think at Sun in 1996. Mark Redhill. Hi. Ando Haley. I'm Java platform lead at Red Hat but that's not the position that I take when I'm sitting on the governing board because I'm a community representative. I'm not representing Red Hat, I'm representing all of you. My name is John Wiewicz. I'm from IBM. I've been working on Java as long as pretty much anybody. It's based on my age and I'm very interested in keeping the open JDK community open, vibrant and inclusive. That's why I'm here. Doug, do I introduce yourself? Yeah. I'm Doug Lee. I write code. I teach classes. Every once in a while there's a governing board meeting that I don't space out and actually, actually, I can, sorry to people. All right. Well I think that's a good start. I think it's also nice that we're having this session now right after having Brian here talking about future stuff that's going on and the awesome pipeline. So why don't we go ahead and see if we have questions. Do we have a second mic that we can pass around? Sorry, a third mic? We don't. All right. Yeah, well, we'll take the questions. All right. Let's see. Shall we do hands? This is going to be great. There aren't going to be any questions, are there? Oh, we have one here. We have a winner. So this sounded like a technical question about Java modules, which I would be happy to answer offline. It's not really a question for the governing board. Yeah. So the governing board is not designed to be a group that is essentially technical in nature. It's about the governance in OpenJDK. It's about making sure that we have an environment that fosters innovation and handles any conflicts that may come up. Mark mentioned it earlier in his talk where he was talking about if you don't like something, this is a path of escalation in order to say, hey, I disagree with this decision that was made. Is it possible to have it reconsidered? And so we're the ultimate place where that kind of thing could go. And I think we're quite happy about the fact that we haven't had to do anything in that capacity because there haven't been things escalated to us. Yeah, and we've avoided them. We've taken proactive steps to predict conflicts where they've occurred. Yeah, I mean, just to sort of summarize briefly and slightly brutally, the governing board is officially technically incompetent. Now that doesn't mean we're necessarily incompetent as individuals. But when you put us all together. For years, for the first, I don't know, three or four years, there were a whole lot of issues that were mainly process issues that we focused on and got rid of one by one things like the CCC process and testing and things like that. So we, the governing board right now is in sort of a boring, steady state where there's only a few issues that have arisen, including things like maintenance leaders and the like, that have to have even surface to us as governing board, as opposed to us as people who work on Java stuff, which is, you know, it's a career. It's not a one time thing. Yeah, and just to describe, probably the single most recent issue of process and governance that we had to deal with was the issue of the handover of JDK update projects from the maintainer Oracle to the next person, which was a bit of a mysterious process. And it is especially mysterious and damaging to the community as a whole, because nobody knew who and when it was actually going to happen. And we spent some time discussing ways of making it more transparent and more predictable and stuff like this. The things that are really, really important to maintain the confidence in JDK and in Java in general, I think. Tell you what, I will come to you, but I know what you're going to say. So I'll go to you first. It's not perfect, but it's not, sorry, I should repeat that question. How is the vulnerability group coming along since last year? It's not perfect, but it's not imperfect to do with the way that it's constituted or its processes or whatever. It's imperfect in the way that human beings are imperfect. So we've been having with problems with patches being delayed. Sometimes we've been having communication difficulties, all of the usual things that are almost unavoidable. We get, I think, a little bit better each time. But the last quarter's critical update was some of the patches were delayed until really, really too late. But I don't think that's something that you can do by making rules about it or by laws or anything. It's just, you know, stuff that happens. We'll try not to do it next time. Well, I'm not sure you're going to be allowed several questions. I think you should pick the most significant one. The last vote for the minutes is today, which I haven't done. Volker is stating that there hasn't been any done on the governing board because there's no minutes posted on the website, which is correct. And all the minutes are being approved as of today. And I haven't sent my votes in yet. But as of today, yeah, we're, George is bad. Yeah, so there's a process for the governing board minutes where they are sent out for a comment from the folks at the governing board who are at the minutes so that we can make sure that they're accurate before they're sent out. And so there's a whole bunch that are just about to come out. It would have been nice if they had been out today and then- Deeply controversial. So we would be screaming to get these minutes approved. I guarantee that you will not be able to use them to stay awake. Go on, although he's next. I don't want to do that. And okay, I will repeat that question as accurately as I can possibly remember. The question was about downloads and specifically downloads of binaries. Is that correct for the upcoming- I think you mentioned JDK 11, but I also want to answer that for JDK 8. Oracle have up to now been building binaries and making those available using Oracle's Java.net infrastructure. I want the JDK 8 updates project to be able to stand on its own feet independently of Oracle's infrastructure. Therefore, I want to work with adopt open JDK and others to make official JDK 8U binary releases available whenever there's an update. Yes. I just want to make this clear. JDK.java.net is completely separate from open JDK.java.net. They share the domain which is a stupid historical accident, but there it is. JDK.java.net is where Oracle posts builds, and that's all it's intended for. Open JDK.java.net, the set of community domains, there are no binaries, and that's by design. And it's my belief that the more we can stand on our own independently of Oracle internal resources as open JDK community, the better. Yeah, this is to do with Grail, which although it is Java, it is entirely independent of open JDK and has been run as a separate project by Oracle Labs mostly, I think these days. And the question is how can we work with it as contributors to both Grail and Java? Or how will it be brought into open JDK? What did you mean? Yeah, it's going to be tough for us to answer that as a governing board because Grail is very much outside our remit, but I'm going to give him the microphone anyway. This is a hard one. So I would actually modify a little bit what, well I wouldn't modify, I'll clarify a little bit when Mark was talking previously about Metropolis. The general effort, I'm sorry when Brian was talking about it, the general effort of Metropolis is the notion of building a Java compiler in Java. And looking at the advantage, do you want to? If you read the project page, the general notion of Metropolis is to rewrite as much of the JVM as possible in Java. It's not just the JIT. That's where we're starting. Grail is the leading candidate for replacing C2. But long term, imagine, I don't know what, 10 years from now, the JVM in the open JDK community is written almost entirely in Java and maybe they're underpinnings and maybe the GCs are still written in Rust or something. Right. And we can finally get rid of C++. Yeah. Anyway. But I think if you sort of view it in that lens, Grail looks very promising as something that could be a puzzled bit on the way there. But it's too early to say that it definitely is. I think that's going to depend in part on what people working on Grail think about that. And in part it's going to depend on what people working on open JDK feel about that as an approach. And definitely feedback on that is welcome. Why am I surprised? As really just an aside, as a core library developer, I always try everything I do with those C2 and Grail. And Grail's better for a few things here and there, not everything by one slide. Consider Open J9 too while you're at it. And I should have said that. I don't religiously test it but everything is also run on IBM and J9. Right. So the question was with a lot of vendors getting involved with producing their own bills based on open JDK, is there a way of coordinating work on addressing vulnerabilities and making it so that there's shared work on security and the technology as a whole is secure? And so we had a question earlier about the vulnerability group. That is something that was created, I think it started its work really about a year ago. And that's exactly what that is. So that is something that is intended for people who either have deep knowledge and expertise in areas and can bring it to bear. So it could be that they're a security expert, it could be that they're an expert in difficult parts of the JDK where we think we need that expert in order to make sure that addressing vulnerabilities is done in a way that doesn't affect compatibility or have other kinds of issues. It is also a group that is intended for people who are working on downstream implementations of open JDK. I understand. So one of the things that the vulnerability has as it's set up and it's not in place yet, but it's on its way, is a mailing list where people can send secure reports of issues. Yes. Yeah. I mean, there's a deeper sort of political question here, which is do we really envisage a day when the open JDK vulnerability group is the primary clearinghouse for Java vulnerabilities rather than Oracle? I mean, I certainly hope it will. It's possible my colleagues on the governing board may have different opinions, but you might argue that the governing, sorry, the vulnerability group isn't really quite mature enough for that yet. But I would certainly like it to be that way one day. I think it's an excellent long-term goal. I do too. I think the right answer is the community that's building the runtimes should be able to share vulnerability reports evenly as soon as they're reported. But the reality is there's also distros that have products and some of the vulnerabilities will come through that path and those have to be also be brought to the vulnerability group via the internal path. And I think that's what you were referring to the politics. Some of the inputs that you get as a large company, I'd be a moracle, whoever may not be allowed to take those back. So we have to fix our internals in addition to share with everyone. But if they come in the front door at adopt or I said adopt my apologies at open JDK or you're welcome. So if they come in straight at the vulnerability group, then everyone gets them right away and then they can determine if the distro they have actually has it because it's not going to apply everywhere and then everyone can take those back to the product teams. So I think it's multiple sources. The other thing to bear in mind is that no member of the vulnerability group is obligated to share what they know immediately. It's fairly commonplace. I'm sure among all of us that we sit and we cogitate and we look at it for a bit before we decide to share it. And it's very, very difficult to strong on people into doing that. Yeah, you can't hopefully eventually everything will go to the vulnerability group. But at the moment it's just the mailing list. It's a mailing list of some pretty serious experts. It's true, but it doesn't have like a super sophisticated infrastructure and so on. We will get there will become more mature. We'll sort it out. But yeah, yeah, that's that's that's a good question. We are the question is which what vulnerable do we only get to see 11 and 12 vulnerabilities within the vulnerability group. And we have to backport them is there a possibility that Oracle might know Oracle. Well, don't want it to single you out but might know about an eight vulnerability that you don't tell us about. I just said that nobody was obligated to share. So it's a possibility. I'm kind of hoping that on ethical grounds, you probably wouldn't do that. Thanks. Yeah, look, so what I would say is this, the vulnerability group is really just just getting spun up. It's been an existence for a year. And so that's been a small number of these quarterly releases that have been done in that. I think the primary work at least, you know, Oracle's primary work and that is always going to be focused on the future because that's where we want to be focused most, right? And that generally speaking, the vulnerabilities that we find don't tend to be weird corner cases that are only in some old version. They tend to be things that are, you know, in the path of things going forward. Now, having said that, you know, the actual fixes that may apply could. So when I say that, the vulnerability may apply across a number of different release lines, right? But how best to fix it may be different in different release lines. And so I think there's sort of different parts to distinguish between one being the knowledge that a vulnerability exists and having people work on and collaborate on how best to fix it. And, you know, the question then becomes, well, what about, you know, backwards of a specific fix and that kind of thing? It's always been a priority for Oracle to try to make sure that people using Java are safe and secure. If Java has a bad reputation, that reflects badly on Oracle, right? So, you know, we don't, like, our general approach tends not to be to go out and say, you know, Oracle is the only secure version, no other implementation is secure. What we want to say is Java as a whole is a technology that is secure. It's a good technology to use. And that's the thing that, you know, for us is most important. So, you know, what I, what we would like to see happen over time is for there to be more people taking part in that discussion, right? And that's why we created the vulnerability group, suggest, and it was a bunch of work, I can promise you, you know, to make that happen. I personally had to arm wrestle multiple lawyers, not just at my own company. So, you know, that's, that's, that's, that's rough. So, I would, I think that it's, it's a good start. And it's really, I think that what you should view the work that's going on in the vulnerability group as is a little bit of a formalization and a simplification of work that's always gone on, right? This is not the first time we've had a code line for a major version of Java that has gone past the end of public updates and Oracle no longer contributing backports of fixes. And so we've seen that happen on six, we've seen it happen on seven. And as it happened, we've still had a dialogue with other vendors, whether they be commercial licensees of Oracle's code or whether it be people who are working on implementations based on OpenJDK. And the, the, in reality, the challenge that we had in the past was there was no agreement that allowed us all to have a discussion in the same room. What we, basically, it was incumbent on Oracle to have individual discussions with all of these different parties. And so that was very, very, you know, challenging and difficult and expensive for us to do. So, you know, we're quite happy to see, you know, the infrastructure put in place for that discussion to be one that we can all have together. Doug, do you want to say anything? He can't tell you're looking. Yeah, I guess not. I mean, just one small thing I'd like to say about all that. Speaking for the community in the vulnerability group, my priority has never been to demand of Oracle, we want your patches for bugs in older JDK releases. My demand, and I think it's a perfectly reasonable, I don't use the word demand very much, but I think this is a perfectly reasonable demand is to say, just tell us about the bugs. Tell us what they are. We can write the patches. Have we had you yet? No, go on then. I, can we sort of agree this might be slightly outside our remit? Oh, go on, Doug. You've got a minute before I talk to somebody else. Doug, are you willing to give up CVS by 2025? You know, the reason we use it is because there are so many academics who trace all of the long stored in history. You feel concurrent. And Malik, by the way. So, yeah, any decade now. Okay. Somebody would have to convert all of the checking comments in a way that these other people can come. The last I asked was maybe like three, four years ago. And there are these long-term tracking studies that I don't know. I can't give myself to Yeah. I believe what we just heard was my Martijn volunteering to do that. Say that again. I think that was Martijn volunteering to do the conversion. Okay, who else? Yeah. There's no way that you're going to get any answer other than a straight stone wall out of anything here. Anybody up here who, come on. No, sorry, we just can't answer that. No. I have no fear. Google it. And the top hit will be an article that you can read. And there will be some. We'll wait and see. The question was to do with possible lawsuits that may or may not have gone on at some point in the past and may or may not go on in this at some point in the future between Oracle and Google and whether they were good or a bad thing or not and will it affect Java? And the answer is we have no. Yeah. We know nothing. Yeah. Okay. Well, I'll give you my opinion on that just before I pass it over. The question is about the bar to entry for contributing to open JDK. It's still pretty high, but it's high for two really quite distinct reasons. One of them is procedural, which is the sort of thing that we all chafe about. But one thing that all open source communities have learned is that you really do want to keep an audit trace for perfectly good copyright reasons. And also this is an incredibly precious code base. We really, really, really do have to protect it. We have to exercise stewardship as Mark was saying this morning. The second issue is more to do with simply facing reality. We know that because history has shown that lots and lots of people come in and fairly naively make tweaks to the class libraries in particular. And these have all kinds of weird effects that even really quite serious experts in the class library couldn't really have predicted even for doing fairly minor things. The ramifications can be quite deep and you just have to know a lot of stuff before you can safely mess with it. So honestly, could we make it a bit easier to get in? That would be cool. Could we make it really significantly easier to get in so that everybody could play? Probably not. I root everything you've said. I mean, people sometimes look at the open JDK community and say, oh, well, there aren't that many regular contributors. But look, the goal has never been to maximize the number of contributors. So I was saying this morning what we want are people who show up for the long term, get deeply involved in it and invested and develop the expert level knowledge that's needed to move the platform forward. There are certainly kinds of open source projects and communities where drive by contributions of a little patch to do something and then you never hear from that person. Again, that sort of thing can work. The JDK is not such a code base. I also agree with everything you guys have said. I also think that there are things that are going on to make the bar easier. I'll give an example. Every year when we come here, Doug has one thing that he complains about, which is what used to internally at Oracle be called the CCC process and is now CSR. So this is something that has been made more open and transparent than it was. It doesn't necessarily make it easier. It just makes it easier to understand, less mystical. And I think that's the kind of thing that helps explain to people what it is that is needed if you're going to come in and start to work on the JDK and sort of helps make it clear what some of the priorities we have are as we're doing that evolution. I think there are other things that have happened there as well. There has been some initial discussion and work on a project called SCARA. We actually haven't talked about that here today, but I think that's one that you might find interesting to check out. And that's looking at things that we can do on the infrastructure, considering other types of source code repositories than the Macurial that might be a little bit more popular and people might already happen to know. I'll just leave it at that. CVS, exactly. I think SCCS. And then another thing that has occurred and actually will occur very soon is we had the first meeting, which we called the Open JDK Committers Workshop in, when was it, August, where we actually had a bunch of people get together and have face-to-face discussions, which, again, I think is something that fosters the community working on Open JDK and also can be something that people then can look at. And in fact, a number of the talks from that are actually available as videos that you can just go and look at. So hopefully you don't be too upset with me, but I completely disagree in some way about this, making it very, very difficult to join Open JDK. The bar being set very high for contributions is valid for protecting the code base. I agree with that. But telling people that and the process made where you have to really, really, really want to join Open JDK and start to participate and contribute, that bar is a little high for the amount of things you have to do. And the reason it's a problem is you get contributors who go try, they've got busy university students, they're smarter than all of us put together and they go, too much pain in the ass, I'll go work with somebody else. And so you're excluding people who really could help and contribute, but you're turning them away very, very early and you only get the stubborn ones, maybe I'll point here, just for fun, but the stubborn ones who just keep at it and whack their head against the process you've put in place to make, and they go away. They go, it's not worth it for my time, my time's worth a lot more, and they don't seem welcoming. So I want to caution any of this, I really want to get only the best coders and the guys who are really people, guys and gals, who really spend the time to earn all of this stuff, they have to earn it. No one said that you're allowed to change the JIT. We don't let people change our JIT unless they've heard it. We have the bar to join and give contributions and give feedback. So the community has to really be welcoming and that patch that you don't like, feedback and all those things. So I understand why, I don't screw your logic in terms of I really want to protect the code base, but you're not going to get the people who you want working on your code base, our code base, the OpenJK ecosystem unless you allow them in. Feel free to counter, but... Yeah, just one thing for me. Okay, I take your point. I remember what it was like for me as Red Hat to begin with and it was incredibly annoying and frustrating, but it was quite a long time ago, so it's possible that the memory is dimmed rather. Yeah, and I think, you know, lest anyone go away feeling like what they heard was, we don't want more contributors, that's totally not true. What we want is, what we don't want is a ton of people coming and essentially distracting everyone from continuing to do work. We want people to come and we want them to be productive and that's why we have things like mailing lists where anyone can come and join and you can post, right? There's no issues there. Where we've continued to increase the number of people who have demonstrated that kind of commitment, getting access to be able to report bugs directly rather than having them go into the holding area. And so, you know, it definitely is the case that we want to welcome that, but we just want to make sure that we have a balance that we're able to handle that. And I think if you sort of look back, the record will show that, that pendulum has been swinging regularly as we put in place more of the systems to kind of make scaling that up possible. Just to follow on a couple of things. It's really hard to contribute even a new sentence in Javadoc for a core library class as we see all the time. Somebody says, I don't like this, can I fix it? And then months go by of people iterating through fixing that sentence. It is tough. Nobody complains that people give them a hard time about accepting new test cases, bugs, anomalies, things like that. Of all the things that people can do that is really helpful and not subject to a whole committee's worth of people thinking, does this change the intent of our spec or whatever. Things like that are really, really helpful and we don't get nearly enough. And of all the things you can do, that's like the easiest. If you don't like something, make a test case. And then maybe help fix it, but the help fix it is stage two. Yeah, thank you. I must admit that I would be terrified of making any changes to a method specification. Moving a semi-colon could have devastating effects and cause nuclear power stations to explode. A test case is just a patch. Yes, that's true. If you haven't yet become a member, well, hold on, you need at least author status. Okay, there is a problem here in that I'm going to say, well, you send it to a mailing list, but of course there's nobody reading those mailing lists whose day-to-day job is answer or such things. So there's always a possibility that that might not be noticed or might be ignored or something because people are busy. Or it could be, you asked a really tough question and it's like, oh my God, I don't know what to do. I have to deal with this a week. Happens to me and sit along. Yeah, I mean, all I can say is that I try to answer things like this, and I'm hoping that everybody who is granted the privilege of being an open JDK author has some regard for having to answer questions like that on the mailing list as well. But people are imperfect. At the, sorry, at the back there, go on. Any bugs that have, security bugs, sorry, this is a question of whether patches, bugs that are found in 12 and 13 will get backported to JDK 11. I'm assuming that somebody gets appointed to be lead and that project continues. It will then be up to whoever is running that project and the volunteers who are working on that project to backport them. There is the infrastructure in place now within the vulnerability group to make that happen. And I have every belief that somebody appropriate will step up to be a JDK project lead and do that work. Really, they're complaining and we don't want them to participate. Yeah, yeah, I hear you. Take that job, please. Next hand up is the volunteer to support them. Yeah, yeah. Apparently, we have, as usual, hit the end of our time. We will be thrown out of here soon. We don't want to be unpopular with the lovely people that are running FOSDAM and also the lovely people who clean this place, the staff that work at ULB, wonderful people, all of them. So thank you very much. One thing I would ask you all to do before you leave, which is hopefully something you're going to be doing very quickly, is look under your seat. If you find any letter, please pick it up and take it away. Thank you very much. It's been an awesome FOSDAM, good night. All right, quickly, quickly. All right. Thank you, Doug. I'm gonna disconnect now. Thanks. Appreciate it. I'll talk to you soon. All right. Bye, everyone.