 Okay, we're going to get started here in just a moment. We're doing our best to get Professor Doug Lee on Skype. One could probably question our choice of methods of getting him here, but in any event, we're going to see if that works. Other than that, I'm actually pleased to say that I think this is the most complete representation actually being physically here in the room that we've had in one of these sessions in beat space, as Andrew says. And so we'll just start out and quickly to make sure everyone is in the right place. This session is the Open JDK Governing Board Q&A. And so of course that means what we're going to do is let you guys ask us questions and then we're going to do our best to answer them, right? That's how it works. And so before we do that, we'll just do some very brief introductions. So hi. I'm George. George Saab, I'm the chairperson of the Governing Board. I work at Oracle. So I'm also the vice president of the group that works on Java SE and ME and Card and associated stuff at Oracle. And I'll pass it to Andrew. I'm Andrew Haley. I work at Red Hat, but that's not how I got to be on the Governing Board. Hi. Hey, there's Doug. All right, Doug. How's it going? Oh, Doug's a tool. I'm going to turn it around. Yeah, yeah. Anyway, sorry. It's going to be like that, isn't it? I work for Red Hat, but I'm not on the Governing Board representing Red Hat. I'm there as, well, I'm there to represent you, really. I'm the at-large member, one of the at-large members, sorry. I'm along with Doug. And I'm there because I want to represent you and the rest of the open JDK community. I don't represent Red Hat. No. We're going to try that. Oh, yeah. Okay, go on. Go on. Don't talk to us. Just try that. Doug? Hi, I'm Doug Lee. I'm surprised that I'm here on somebody's phone. I'm just like Andrew, just like he says. I'm here to represent you. I focus on academic research community, but hackers galore. My name's Mark. I work on Java. Oh, and I work for Oracle, so. My name's not Mark. Luckily, my name is John Dujovic. I work for IBM. I'm the vice chair of this fine open JDK governing board. And I'm a distinguished engineer, and I own all of the runtimes, including Java at IBM. And since we've been participating since 2011, somewhere around there, in open JDK, as most of our Java runtimes actually built on all of the class libraries from open JDK, we're interested in continuing the innovation at the community with community members from this audience and others. All right, so this is Q&A, so before you do the question, let me just say one thing. The very first time that we have all the governing board here, so for me it's a great thing. It is beyond exciting. I'm so excited, I cannot believe it. Okay, and Mario, are you going to run around with this thing? We're going to make it, because that one's for Doug, we're going to make it. Sorry. Okay. Well, all right, then people will have to yell. All right, Sonny. Yes. The question which I should repeat for posterity is what's happened about the open bug databases because we were talking about that last time, or a couple of years ago, I think it was. We're doing okay, kind of sort, is my take on it. Open JDK members can create bugs, but nobody else can. Other people go through the Oracle gateway, which I think, am I right in thinking that's a general Java bug gateway, rather than a specific open JDK bug gateway. That probably makes sense because end users don't necessarily know whether the bug that they've got is specifically open JDK or generally Java related. There is a problem in that until it's been triaged by staff at Oracle, it's quite hard for people to know what the status of the bug they've just created is. That's an ongoing problem. On the other hand, I think that the high quality bugs that we need in order to be able to act tend to be created by people who are open JDK members anyway, because they have the requisite knowledge to create all of the information that we need and to produce repeatable test cases and so on. I would argue that this still isn't an ideal situation, but I do understand the reasons for it. The bar is actually not that high. If you change that, you get the author status and you have the access. Yeah. For posterity, Alexi Shiblov was saying the bar actually isn't that high to get to author status and then be able to get access to the database. I should point out that database is one, and I don't know exactly which year you were talking about Sunny, but definitely in the beginning, we had a bunch of work to do to actually move from the legacy bug system that had been used by the team at Sun to the system which is being used today. It is the case that you can go and look yourself and see the bugs, see what's happening, see what responses people have made. The only thing that is a bit of a challenge is if you want to go and report a bug directly and you haven't done a bunch of work and made contributions and gotten some level of status in the OpenJK community, you need to do that through the sort of bug reporting system which is for Java users in general. One of the reasons that we do have that at the moment is we get an immense amount of traffic there. There's really a lot and I think it would not be ideal to have all of that traffic going directly into the OpenJK bug database because there's just so much noise. That's true. Sorry, Alexi points out as I was just about to say, 95% of that are Minecraft video driver bug reports because when the VM crashes it gives you the URL to that exact page and millions of people dutifully file their Minecraft crashes. There's a third channel that's worth mentioning. It's not a huge source but it's not uncommon for developers who are familiar with OpenJK as a community but not real active. They'll show up on a mailing list and say, hey, I've got this problem and then somebody who does have access to the database says, oh, yeah, that's a problem and they basically create the bug for it. That happens on an informal basis pretty frequently, I think. So if you're in to follow your bug, could you say that again, Doug? I said if you would like to be a member, because you found a bug and you'd like to help fix it, the easiest path is find somebody else who's already a member, they can file the bug and then you can collect brownie points for your membership. Well, yeah, and that's basically the algorithm for how to get involved is you find somebody to help you. That's true for many things. A different question in the back. In terms of non-X86 platforms, how are we doing? Spark is doing great. How are we, I'm trying to remember what he said. How are we doing in terms of, was it features and testing and quality for them? Yeah. Well, let's just go through the platforms. The non-X86 OpenJDK platforms. There's PowerPC, S390X, ARCH64 and Spark. ARCH32. Oh, yes, I suppose so. Some people think of that. That's awesome. I agree. The ARCH32.64 port and the Spark port are also tested by Oracle. Correct? The Spark port certainly is. The combined one is too. Yeah, okay. Yeah, that's right. Outside there, we have a number of partnerships in the community for things like the ARCH64 port. S390X, I don't know. I mean, you guys must be testing it, right? Along with the PowerPC. We're doing testing at Red Hat. I mean, one thing I can guarantee is that we're running the regression tests and we're running TCKs. So we do know that the other ports are compatible. What we don't have outside Oracle is the big bunch of heavyweight applications, which I believe you're doing regular regression tests on. And it's something of a challenge for the community to pull together a whole bunch of big stuff that we can use for testing. Yes, that's still very much a work in progress. And in order to get everything up to the same sort of high level of quality, we're going to have to do more of that in the open. I understand. I mean, a lot of your tests that you do internally are proprietary anyway, so can't easily be opened up. Okay, I'm not entirely sure. I understand what... I think you're asking why don't we have HTTPS? At the very least, for those of the people who can download the source code securely and have some assurance that there's no man in the middle giving them source code with bugs, this has been bugging me for quite a while. And it's something that I've been meaning to talk to the info team about. Just haven't gotten around to it yet. We should do HTTPS preferably only on all of the open JDK infrastructure. We already do it on the bug database, I believe. But for all the rest, we should do the same thing. So we need to work it out with the info team and the way we need to do it to do a few internal oracle approvals to get the certificates minted, but that's pretty straightforward. So, yeah. You're doing pretty good. I want to place for the website. What do you got? Volcker. Oh, so during the last year, I was always complaining a lot, so this year I'm quite satisfied with Volcker. Whoa. Volcker says he's quite satisfied. He's usually the guy who stands up and he's got a list. And he reads from the list. And as he goes down that list, you know, we're all up, and he's like, oh, oh, no, oh, oh. I have maybe just one question this year. Recently, we had a problem on the Open2DK meetings. Somebody was complaining that the class library had a check-in with some folks from Stack Overflow and a personal check. And I see in the end it turned out that the guy who was published was from Stack Overflow, also an oil company. So I don't know if it's such a big problem. But my question is, are there any plans to do something like code scans or to code some more checks on the code that should come in like Apache or Azure? Are there any plans to do code scans to catch code coming in that maybe shouldn't be coming in because its provenance is unknown or uncertain? Xerxes, do you have another question or did you want to comment on that? Another question? Okay, you're just being very diligent. Very good. Or maybe you've got a cramp in your stretching. That's fine too. Yeah, so the whole code provenance and all that, Oracle doesn't have any current plans to do any more. Do we as a governing board need to encourage someone to have plans for this? So far the honor system has worked pretty well. We did catch that one case. We got a lot of lawyers. We scanned the shellac out of everything. So if you didn't think it's being scanned, it is by us. However, however, thank you IBM. You're welcome. But it would make good sense because the problems of the code, stuff happens. I think we should have some policy that would help us for sure, but probably helps others because there's a lot of ways to get the wrong code in the wrong place. And you guys are probably motivated at the same time. I'm surprised you're not scanning it or you're not admitting it. But here admit it. Well, I will say that there are a couple of things. I think in general code scans are done whenever, you know, whenever Oracle does an acquisition, we look at all of the inbound IP. And so that certainly was done. In fact, it was quite humorous when that was initially done on the JDK code because it immediately came up with, you know, lots and lots of warnings of things that were in some other bit of code. Because they were in the JDK. And so that's kind of interesting. No, no, no, no. I mean because it was actually, you know, code that was in the JDK, which is a known bit of code that's out there that people shouldn't be copying and using except this was the JDK. So that was kind of interesting. Thanks, Black Doc. In any event, I think, you know, one thing that's worth keeping in mind, I think, you know, many of the folks who work in the open JDK community work at companies who have pretty strict rules around this kind of thing and are pretty used to that. I think that, you know, we do have some people who are sort of individuals who come in and work that may not be as used to that. It certainly is the case that the OCA has information about what's expected. So, you know, when you sign up and say I'm going to, you know, I want to be a contributor to the open JDK, one of the things that you're saying is I'm going to be diligent myself about not taking code from somewhere and, you know, kind of contributing code that's not mine to do with. And so I think there already is that, you know, whether we, it makes sense to put something more in there. I think, you know, we've seen kind of one case where we had a question, you know, possibly surprisingly, I don't think we're aware of any others. And so, you know, my feeling would be, and, you know, we're kind of having a governing board discussion here in real time, is that, you know, unless we start to see that this is something that's clearly a problem, we don't necessarily need to worry about introducing additional friction. Yeah. Policy when it comes up. Whenever these things seem like they might require involvement by lawyers in creating more process documents, we cringe because that's open JDK governing board at its worst. We don't do anything because it takes so long to do anything. And a great example of that is something I thought I'd bring up since nobody asked yet is the brand new and thank God it's finally proposed project which was just announced this week and sure to go in effect. And this is finally an open JDK process that corresponds to the evil, secret, secret society of CCC that people live to fear from. And now we have, we will have a process for doing that without a huge process document. I am so proud of Mark of figuring out how to put this into effect without writing a hundred pages about what it does just saying basically it does whatever the sponsoring group would like it to do. I think it's us at our best and I want to publicly congratulate Mark for finally putting it together. All right. I think it's due to the color of Trump orange this morning though, so I'm not sure. Yeah, it's a joke that I think we've made every year and there's a danger of us getting to the end of the session without saying this. So I'll say it again that in an ideal world our job as a governing board is really not to do anything. We hope that the various sub-communities within Open JDK will be self-organizing and they almost entirely are. Yes, there are infrastructure issues which tend to cross boundaries of teams and groups and organizations and all the rest of it. But we're just there to make sure that the sub-groups and all of the stakeholders have what they need in order to organize themselves. We don't want to run people's lives for them. Thank you. Yeah. Yeah, OK. This is all to do with making binaries available. This has always been a very vexed question. I think there are lots of really, really good technical reasons why that is very, very difficult to do. And indeed, the binary may not necessarily work on your system either. Could Oracle do it? Would Oracle want to do it? Publish early access binaries on a more frequent basis. Under what license is always the question. I think Oracle, we've had directions from the business side that shipping binaries under the GPL is not something that Oracle wants to see. I haven't asked that question again for a couple of years, but I got a pretty firm answer the first time I asked it. So we've already been thinking that for 10, it would make sense for Oracle to publish nightlies or whatever on a much more frequent automated basis. The Oracle JDK, it's 99% open JDK, right? It's not that different. But it's under the BCL, which some people won't be able to accept. Maybe other organizations can step up and provide binaries under other licensed terms. Doko, did you want to reply to this? OK, so Doko's pointing out that Debian Experimental and Ubuntu's, what was the Ubuntu one? OK, so the current development line in Ubuntu will have open JDK binaries. Are those updated frequently? Mostly weekly. So that's another source. Are these Linux binary source specific to Ubuntu? Yeah, OK. Yeah, so I think you just saw the reason you don't get a nightly binary for open JDK because there are at least five builds that you're talking about. We have another one, maybe I'll be the sixth. And they are nightly available and depends on where. And so everyone's building from source and there is no binary distribution from open JDK that everyone can then unify on. So that is an opportunity the community would like to do by a distribution project. I don't see why that wouldn't be a problem to just build it. But each of the five of the companies still do theirs and we all have separate builds. So I think that's where you're seeing the challenge. And so everyone goes, yeah, there's nightlies. Mine, mine, mine, and mine. Or you guys have the common one. Maybe Doug has a nightly, I don't know. Even Doug is crazy to have a nightly. So I don't know. But there is, because you want to do the work last night and the answer is where. What code did you get? What did the experimental guys have in there? It's kind of a mysterious thing. So maybe there could be a community effort around it. Another bad story. And we have, of course, a bigger problem. We have all sorts of additional code that's not part of the core yet. So hopefully we can fix that, too. So related to this question, you publish not only your Oracle binary builds, but you also publish test results, which is good. But you only publish the results like which of the regression tests read. But you only publish which results pass and which don't pass. And it would be good if you published the exact test details, the files, the JTR files, because I spoke with Roy about this and I just wanted to bring this to your attention. A lot of tests, I mean, maybe they get not executed on your hardware, on your platform. And the result, it's always OK. So if the test passes, it can mean it wasn't executed. It executed without errors or something in between. So a better publication would be good. There's more details. No, that's a good point. Publishing JTR files, technically, I don't think would be hard. We would probably run a fall of some of the same issues we're having with the experimental submission forests in that we have to scrub test logs for internal host names and other stuff that we're just not allowed to reveal. But maybe we can somehow combine those two efforts and if we have a general test result scrubbing filter, we can use it in both systems. So yeah, it's a good idea. I think we're coming towards the end of our slots and FOSTA and staff are going to get rather impatient with us. So while this is all very interesting, I don't want to stop anybody talking. If there's one more really quick question and then I think we're done. Go on. With additional ports coming into OpenJDK, AR64 and PPC, if there's a security issue to report, there's different owners. Who should I talk to? Okay, so that's actually one of the things that Mark discussed earlier today was the work that we've been doing on proposing an OpenJDK vulnerability group. And I think we're just about there. There's sort of one last detail that I'm trying to get pinned down and worked out. But the intent of that is basically that we have a place where it's very easy for anyone who finds something to come and report an issue so that all of the people who are involved and potentially can help in fixing that issue are able to find out about it and to sort of work with the rest of that group and actually being able to find a solution. And so I think that's kind of how we'll try to work that out and we have a little bit of a sort of guidelines of what people might be people that would join that group and certainly having responsibility for a popular port or something like that would be one of those things. I think another is we've seen this happen fairly often where there's some possibly relatively obscure branch of the class libraries or something where a bug comes up and we really need to be able to find the world's expert on that. And that's not something you want to be doing when there's potentially a zero-day vulnerability happening. So a lot of this is trying to get that all mapped out and sort of work in advance of potential issues coming in so that you're able to act really quickly and we can do that as a community in order to keep all of our users safe. Is that helpful? I had in mind when I said we sometimes move way too slowly if there needs to be lawyers and very careful wording, things just don't go fast and open JDK. Sorry. Yeah, and I think Doug's right about that. What I will say for this particular area is that one of the things that's contributed to it is the need to have lawyers from multiple parties kind of review it in the interest of trying to make it as good and tied in agreement as it can be, but also I think because we actually do have something that works today. It works non-optimally and it's mostly non-optimal for Oracle because at the end of the day, we end up actually often having to have discussions with multiple parties one-on-one, which really should be everyone getting together in a room and discussing. So it ends up being far more difficult and expensive for us than certainly I would like it to be. And so that's one of the reasons we've been pushing for this, but it's taken a while and Doug's completely right on that one. I think in the meantime, what I can say is we have seen situations where people are unsure of where to report a bug and then typically what happens is one of two things. If they're smart, hopefully they figure out where they got to build from and they report it to whoever that is, if it's Oracle, if it's IBM, if it's Red Hat or Azure or whomever. And then I think those folks try to deal with those responsibly as they can. In some cases, we've sort of seen people scratching their heads and then posting details of a potential security vulnerability on public mailing lists, which is not a good idea. Don't do that, please. While people want to hear about the issues and try to fix them, we don't want all of the details of those publicly known because the bad guys are looking too. So what I would say for right now is I think the best thing for people to do is try to report it to the people that they got a binary from. And I know if you're in the business of doing that, it's a good idea where you have downloads to also have information about how to report issues and how in particular to treat security issues. Another way of saying that is even though we do not have good rules in place, we have some good people in place and things are not as bad as they could be. Yeah, things are not as bad as they could be. And I think that is a really excellent time to end this session. Thanks, Doug. All right, Doug. We'll talk to you soon. Take care. All right. Cheers.