 I am Andrew Haley. I am one of the large community members of the governing board along with Doug Lee who is watching online over to you Doug. So I can barely hear you can you talk into something that the the the laptop mic in here. Oh okay is that better? That's much better. Okay for enough. Okay well I was just saying that I'm Andrew Haley. I am one of the two community at large governing board members along with you and this is your cue to introduce yourself. I don't know what Mark is doing to me right now. Okay hi I'm Doug Lee. Did you ask me to say anything? Yeah I just just just say your name. I think we're done. Okay right this is always a little bit on I'm the light entertainment of this panel because I can barely hear you and you can barely see me. Oh well. We can see you quite well Doug actually. I could even that'd be scary. Hi my name is Mark Reinhold. I'm not going to blather. I'm Steve Wallin IBM. I'm replacing John Dumevich who's unfortunately ill today. So I'm the silent partner from IBM on the open JDK but obviously I've got a voice today. So this is a Q&A. Hey George. George is here too. I'm here too. Yeah I'm the the chairperson of this this illustrious group and really wish I could be there with you. I'm sorry personal circumstances made it impossible this year but I know how much fun you're having so it makes me very jealous and I'm gonna turn off video because my connection is so crap that otherwise you won't be able to hear me and I suppose. Okay George you're the chair run the meeting. Awesome. So I'd like to as the first point delegate to Mark. Good thing you're not actually my boss. Okay so this is as I was saying this is a Q&A. Any questions. Mr. Marvel. I can't bring in the mic the mic is an incredibly delicate beast. Why do you jump over. Sorry Tom. So Tom Tom is is very sad that he cannot troll George as he annually has for many years about the closed components of the JDK. And I'm so sad not to be trolled. Did you actually have a question that was that was a comment. All right anybody have an actual question. All right if we want to get past that I think I'll try to start with something that is something I wanted to make sure I talked about before it ends might as well start with it. When we formed the the governing board a few of us had a laundry list of major major initiatives that needed to get done. And they are slowly finally four years later coming to an end. We have some sort of mechanism for for all of the things that were proprietary oracle processes. Some of them are just barely going like the like the test repo. Some of them have been going on for years. The last year we created the CCC replacements CSR which is really boring but important. The vulnerability group is finally out of legal and might actually happen sometime soon. Yeah I'm right. All of these though were our big you know my bullet points whenever we had discussions about where should we be going. And you know I'm actually okay with being designated into boring sustainability mode for the GB. But I would like to make sure other people we are that agree that we are in the boring sustainability mode for GB. So if people have ideas of things that they think we should be focusing on and debating and and annoying the oracle folks until they comply let me know. Gee thanks Doug. Can I make a suggestion if this I think it would this would be much more authentic if people did come down and actually use your own voice to ask your question because when we repeat it we inevitably miss things. But of course if I have to repeat it I can edit as I go. So I have a suggestion. Can we perhaps enter in the first demo 12 times a year that would be really great because like in the weeks before first time there's always so much so many so much happening if we could have that to 12 times a year that would be really great. So do you remember what I was saying earlier about the six month release model and how the rate of innovation doesn't change. It's just the rate of innovation delivery. I don't think your suggestion would have the effect that you want. OK. So some concrete examples. So for example publishing the government board minutes. This always happens like months before first time for the whole year. So that's actually not a good thing. I think they should really be published in a timely manner like weeks after the after your meetings and not months or half a year later. That's one point. So we have been working through that through that backlog. I think there are only a handful of meetings left to get through. So we'll get there. And I agree. They should be more timely. And I suspect everyone agrees they should be more timely. Yes. That's right. Apart from anything else. We can't remember what it was. We actually said when it comes to signing them off. Oh did I really say that two years ago. Maybe. Submission for us are a great first step. But it's actually not submission for us. It's test for us. So we really need a way for external committers to push hotspot state changes which is still not possible. Actually it is possible because the member I said earlier that that internally at Oracle we replace JPRT with Mach 5. Mach 5 doesn't do pushes either. So Oracle engineers can't even do it that way. But now that now that we have the submission for us. You know consult with your local hotspot gatekeeper Jesper or whomever. But now we have that. If you if you are working on shared code you run it through the submission repo test repo. Maybe we should rename it and all tests pass. You should be clear to push it. But yeah Jesper and I were chatting about this a couple of weeks ago. He plans to communicate this so that people understand. Let the record show Volker Volker only had two items on his list this year. I'll take that as progress. I'm James Hunt. I have two questions. One is what about opening the TCK up to general usage. And two I'd like to understand what the what the thoughts are going forward between the JCP and the Open JDK but Governing Board. How that that relationship is going to move forward. George you want to take the TCK one. Second one. My goal is to preserve the distance between the Governing Board and and and ACP to be as maximum as possible. Okay I'm stepping further away from Heather. The laptop is starting to glow with heat. I'll try to answer both of these and hopefully you can hear me and if anyone want to add they're certainly welcome to. On the access to the TCK I would point out that it is possible today for you to get access to the TCK through an agreement called the OCTLA and are many people who have that in order to use the get access to the TCK and test your own builds of Open JDK. Now I realize that's not the same thing as having the TCK in open source and in a place where everyone can easily contribute to it. Although we do have some very good examples of exactly that happening. For instance with 310, 8-time JSR and so I think you know this is an area that probably will continue to evolve and we'll see what we get to on that. But you know I hope that that solution is as somewhat provisional as it is. You know meets most people's needs for anything that is urgent. The second thing regarding the JCP, hi Heather, you're right in the middle of the screen. I would say that there's been a lot of very good work in the last year to basically find places where the JSR lifecycle and the JCP process had some impedance mismatches with the notion of doing six month releases. And the JCP EC has been very cooperative in agreeing that we share the same goal of making sure that the specification side of Java remains strong and that we find ways of making the process fit with today's more rapid evolution cycles. And so there have been a bunch of changes that have reduced the amount of time and overhead in the process which was initially described long before the code base for OpenJDK and thus the reference implementation was open source. And where the initial goal was really to force all those evil vendors doing closed source stuff to be more transparent in the design and implementation process. And of course, purely being open source helps to a great extent with that. And it was kind of high time that the JCP process be evolved to a point where it wasn't something that was holding, sewing everything down. So I think that cooperation is great and we'll see how that continues to evolve as we go forward. We're really, with the first six month releases now, trying to experience how that's working. And I think if we find places where there are issues, we're going to have cooperative partners in the JCP to continue to remove those impacts. Hey, George, I don't know if you've dropped or if you've finished. Just to kind of amplify George's comments, I think there's two examples there. So for the first question, we've certainly been working with the adopt project, the London Java community to get TCK'd Open JDK builds available to the community. And so as that project evolves, we have a TCK available to that project. And we are now at the point, I think, where we have clean builds ready to be consumed. So that's kind of the first example of George's comment that TCKs are available to community projects and people that need them. I think the second thing, I'm actually IBM's executive committee rep on the JCP. And certainly we have been working extremely hard to make sure that the processes and practices that we have at the JCP fit the new rapid cadence that we have on SE and the requirements that we have from the Open JDK project in terms of getting the specifications through the pipeline reviewed and commentary and the feedback cycle with the Open JDK team title. So it's been great to have George and Brian and others come to the JCP and explain what's happening in Open JDK and how the JCP process can really help with getting those specifications through. So I think there's good communication with all these things that can be better. But I think actually we're off to a good start there. And looking forward to seeing 10 come through in quick succession, 11 and 12 so I think we've started that improvement and I think there's always more we can do. I'm sorry, I couldn't even understand it and I'm in the room. Could you make a publishing the, so remember the results of the TCK run are a bit. It's a bit. You either pass or you don't. Yes, so from adoption, if we're publishing a binary and it says that it passes the TCK then it would have passed and so we won't publish anything because everything passed okay. When it fails, there's an internal team that have access to that repository because it is kept obviously sensitive to a certain subset of the community. And so those people would be going through the failures and fixing any issues and resolving those until it passes and at which time then no one needs to see the results. But yeah, anyone who signs the agreement in that project can get access to that subset community that has access to the TCK in the result. Why is the TCK code sensitive? There are multiple fairly deep answers to that question. Maybe one of the easiest ones to relate to. You don't want to know. Sorry? Yeah, well, yeah, I could tell you but then I have to kill you. No, seriously, one very pragmatic point is we're talking about millions of lines of code that we would have to inspect and audit just to get it out there. So this is not, this is not, not something that, you know, I could just go to my laptop and do and, you know, stick it on, stick it on the web and anybody can use it. There are a bunch of long standing in some cases, decades, business relationships, you know, initially established by some that have all kinds of confidentiality agreements that bear on what can be done by anybody with the TCK. So it's just, it's just hideously complex. Is this a problem that, that ought to be solved Sunday? Yeah, personally, I think so, but, you know, not speaking for Oracle. Is it something that we look at periodically as, as the situation changes? Yes, it absolutely is. But it's not open source today and I can guarantee it will not be open source tomorrow. Sorry. I do think, you know, the, the, the specifications are standard and we want to make sure that that standard remains consistent. And so there are all sorts of elements that, you know, we don't want an open source project that then gets forked and then all sorts of complications that occur. So keeping it under some level of control is actually useful for maintaining the stability of the Java platform. I think there are all sorts of implications like that, that run along. We're aware of alpha counter examples, really. Okay. I'm, I'm not sure it's, it's useful to spend more time on this. To give a more proactive answer, to give a more proactive answer, you all can contribute open source TCKs. We're the poster child for that in Java Util concurrent. All of our TCK tests are open source. They are imported straight into the, the Oracle TCK. You can and should do the same with anything you do. Steven, Steven Colbert did the same with JSR310. There's a couple of people's problems, but you can do that. No more about the TCK. Go on. It's probably not the right way to ask the question, but I, I personally, as an entity, I have access to the TCK. And so I'm on the mailing list when I see the communication between Red Hat and Oracle and IBM. So usually the way it goes is Red Hat says, oh, this test fails on Chady K X. And then the answer from an Oracle engineer is usually, oh yes, we forgot to exclude that one. Like literally 99.9% of the cases. So can we trust the results really if you just exclude everything that doesn't work? Now just imagine that, you know, the next scene of the film, big dark room, somebody's pouring over a printout of the entire TCK and they realize, oh my god, 99% of the tests are excluded. So excluding tests is a very routine thing that we do in TCK development. Excluding a dozen, you know, several dozen tests during a future release lifecycle is, well, sorry, in a traditional multi-year feature release release lifecycle is no big deal because in that release life cycle we probably added at least a half a million new ones. So what typically happens is there's a draft TCK, you know, people get that, they run that, you know, we run it on a bunch of different platforms internally obviously, partners run it, Red Hat runs it. And results show up. And if you're a couple of months away from shipping the release, remember the release per the JCP is the reference implementation and the spec and the TCK, you know, the TCK is an engineered artifact just like the JDK itself. We have to be careful about it. We don't have time to go rewrite tests and then revalidate them. So what do you do? You exclude it because the TCK has an exclude list for this very purpose. And one of the regular things that the developers of the TCK do routinely after every future release is go look at that exclude list and try to whittle it down, figure out okay, are that were those tests invalid, were they valid, do they need to be rewritten and so forth. So it's a constant, it's like a sign way that goes up and down with the release cycle. I do think we have a good testbed though looking at, you know, I know this is predominantly a Java SE conversation, but if we look at what's happening in the EE space with, you know, the movement of Java EE to eclipse, all of the RI, the TCKs and the movement of that project, I think if we can see how successful that is, then it gives us kind of a testbed for, okay, well what would happen if we open source the large TCK test set? But I think Christian addressed a valid point because we had this with Java 9, Oracle released Java 9, GA and nobody else could really certify it because there was some tests which didn't pass. And because there is no public communication possible, you always have to, every single licensee has to go back to Oracle and ask what happens and it would be easier if it would be possible to communicate publicly about these problems. Yes, I agree, it would be easier. Come down here. The question about the TCK is how is it updated? Is there a special team inside Oracle that reads the CHAPs and updates it or how is it working? Are there also the open source committers of open JDK involved or is it a completely separate team? So Oracle has an entire internal team that develops the TCK. They don't write all of the tests, as Doug mentioned, some incoming projects have chosen to establish a tradition of providing their own. So all the Java utility concurrent stuff, those tests are maintained by Doug and his collaborators outside. They're all marked, I think they're public domain. Right, Doug? Right. We just throw it over a wall. They throw it over a wall and then somebody in the Oracle TCK team takes them and regularly updates that portion of the TCK test suite. We also do a tweak. We took in the JSR 310 tests from Stephen Colborn. I'm not sure if they're still an open copy out there that's maintained, but I don't think they've evolved much. They have evolved much in the meantime anyway. But anyway, the Oracle engineers who do this, this is their job. They're not also doing open JDK or VM work or whatever. And it's a fairly specialized kind of field. You need a fairly perverse mindset to go. You know, they sit there and read through the most obscure corners of the JVMS and the JLS and come up with new ways to beat on the system. But it's really good for quality control. The other set of tests that are regularly done are the so-called JT-RAG tests. And they can be, they're allowed to be a complete overlap with the TCK tests for all that matters. And those are, that process is a little more straightforward because every bug report has some tests. And that test eventually gets itself into JT-RAG maybe by modifying another. Somehow or another makes it in. And so many of the tests that aren't in, that are in TCK are redundant with ones you run anyway that anyone I think can run. It's painful. You need, if you ever want to do it, grab our Antscript from WTIL concurrent and it will guide you through it. It's a little weird. You have to get the right jar files corresponding to any particular addition. But you can run those yourself. And you can get all the, everything you need to do it. Yeah, just for those who don't know, the JT-RAG tests are open. They're in the repo along with all the code. So there's nothing closed there. There's a small number of internal JT-RAG tests that Oracle's going through and either throwing away or putting out into the open one. Yeah, if there's no very strong objection, I'd love to move this on because we have the change to the release cadence which is the most important thing that's happened this year and probably the most important thing that's happened for several years are in, I'm JDKLand, and the people here would love to get a little bit of feedback from you about how you think it's going. My take on it, the last few weeks have been pretty bumpy, particularly with JDK9 and the way that the release happened and the way that it broke a couple of important targets and so on. And all of this is a consequence of the pace of change being a little bit frantic in my opinion. And I think that we can do better next time and we'll probably figure out how to do better next time. I was personally very supportive of the change to release cadence when it was first mentioned to me and I just thought great let's do it. The situation before was that if you were a student and you were doing something for Java for your final year on the graduate project you could probably have your PhD pretty much done by the time it actually appeared in Java. And clearly this wasn't any way to encourage people to contribute to it in JDK. And this I think is much better. It's kind of hair-raising at the moment. I mean no sooner do you think you're ready to put something in and they say oh well it's frozen now from it. Well I only started a couple of weeks ago. But I think we'll all get used to it. I would love to hear any comments from anybody in the audience who's been affected by this this change. Do you like it? Do you think it's better? Do you think it's worse? All comments welcome. Including. I can say a little bit about it. So at Twitter we use obviously the JDK and and we have the M team and we build our own JDK so it affects us a lot. Our biggest discussion point is what are we doing? Are we going? It's mostly about security right? Are we doing every six months the release or are we going with LTS and then what happens if between the LTS releases a very important feature comes out that maybe our scholar developers want. What are we doing then? Are we taking that feature and backporting into the LTS or are we then jumping forward to do the six? So these are the problems we have. So far it looks like nobody wants to do the six months releases because it's it's too fast for our users. Let's call it this way. So we still don't know what to do. You have a choice now. You didn't have before. This is a new choice. Nothing has been lost. You've got something extra. Exactly. Yeah and my take on that is that I think once we get the the vulnerability group up and running it'll feel quite different. At the moment the prospect of having to do urgent security backports to several live short term releases is quite terrifying and I I don't think we could do it but I think given the vulnerability group we'll all have a bit more bandwidth to look at how many of these things are still out there and particularly for Dora which has a slightly longer support lifecycle than the short term Java releases but not much and we'll probably be able to keep those going I think if we have enough time to do it. At the moment it's a matter of we only have a couple of weeks really to get everything backported and merged and clearly we're not going to be able to do that with all the releases. Just to comment that it's a new choice and nothing's lost. I think people have got used to a pattern of behaviour where there is a publicly available free Java version in Java 8 case four and a half five years that's available for download with regular security updates that they can rely on. I think in the new model I think you described this morning a six month minimum in terms of source code security updates in OpenJDK and binaries that are available for these new releases. I think until we see who's going to step up in the community to have longer releases on the LTS then I think there is still confusion and uncertainty about the guarantees for source code security updates and binary availability and that's why we've invested in the ADOPT project to be able to describe our roadmap and plans of at least a four year LTS to get people from one beginning of an LTS to the next with security updates. Yeah my feeling is that it's very likely that something like that model will become more widespread generally and that there will be backports for security updates for longer than three years but these are early days we're just dipping our toes in the water right now. Yeah and as I was saying this morning these are all these are all lower bounds right. What happens in OpenJDK nobody can nobody can predict and it's not please it's not just up to Oracle. So to exactly that point we were talking Twitter we are talking to Google and Alibaba and SAP as well and I think what we should do is I don't know about Redhead the six months releases that are not LTS releases you know sometimes we might have to pick up one just because and it would be good if all non Oracle companies who are heavily involved would pick that up and share the burden of backporting security patches and things like this. That's what the group is for. Join us. That's what the group is for join us. That's what the vulnerability group is to share the information on the fixes and give them out there and then there's the work of actually doing doing the updates and I think you know some of the rough edges that Andrew mentioned that we're you know we'll no doubt iron out over time will allow for appropriate delegation within the JDK updates project so you don't have to wait for some Oracle person to to bless something anymore. Well we want to be part of it but it's not there yet you know we're talking to you and you know I think Volcker has something to say about this. Well I mean that's exactly the point I understand that Oracle doesn't want to commit to this but at least it should make it possible for others to work on this and it's currently not easy the days one one JDK updates project it's not really specific anymore Oracle is leading this project and I don't see from the how this is supposed to work like when you don't want to support Java 9 anymore but there is no Java 9 updates project it's not easy for others to step in so how is this supposed to work is there a process change in in do you work on a process change or what plans do you have here. I think that's still up for discussion. Yes I the co-maintainer of Java 2.concurrent truly believes that we should have some 9 update process for things that are too important not to do I believe the current status is that nobody's opposed to doing it and nobody wants to take control of it. Okay so this morning I put up a slide and the last item on the slide was Oracle commits to ensuring smooth transitions. What does that mean exactly? Well this is the thing that we're still trying to figure out the thing that we didn't do so well a few months ago so we'll do better next time. The fact that there's one JDK updates project that was meant to be a feature so that we don't have to spin up a whole another project every six months which would be a bunch of process overhead that well maybe a few people want but I certainly don't. The JDK the earlier number JDK updates projects eight and seven was there one for six I don't remember those projects established within themselves simple rules for the project lead to delegate for a certain line to some other person in the project there is absolutely no reason that cannot happen with the JDK the general JDK updates project and I expect its project lead to propose something in due course along exactly those lines we don't need a process change we don't need a new updates project every six months this is this is all pretty straightforward I think. No I think that's right and the JDK 9 update tree has not been made read only until we figure out exactly how to do it which we should be able to do fairly quickly I think and possibly in a way that requires me to volunteer to be the project lead or something then we'll be able to put changes back I think but it just doesn't have to be a project there only has to be a tree it doesn't matter well I love working on JDK but all this process stuff drives me completely crazy we will make the patches we will fix. Yeah this this this isn't hard this is not a hard problem to solve so a comment on that it's just an additional choice nothing went the way for us what was impact us is that the short overlap of support period between 8 and 11 we have regulatory requirements that we counter on end of life software previously we had like one day to migrate in production now we have four months it's going to be tight from whom do you get your binaries from Oracle and how much do you pay for them we look at licensing from Oracle but the way Oracle licensing works with VMs there are there are there are other vendors and this is the free Java room so we should probably not talk anymore about Oracle contract practices this is where I would say we've been working with the adult project London Java community plenty of other partners on producing open JDK with hotspot and open JDK with Eclipse J9 binaries and we're going to continue to provide security updates in those code streams so certainly from a Java 8 perspective we're looking for the next few years of having Java 8 binaries that people can rely on and we'll do the same with 11 and we'll do the same with the LTS releases so that that's going to be our plan is look at the adopt project and then you can consider that as a free source of Java binaries that's a great thing to have that in adopt open JDK but what I want to avoid is to have security updates done in adopt open JDK project there should be done upstream and there should be a possibility to do that no no no so yeah so what I'm saying is you know for for Java 6 I know Azul is taking on that burden today of back porting for Java 7 I believe you know Red Hat have got that responsibility Java 8 I guess that that code base won't come to the community until at least January 2019 sorry sorry Oracle is part of the community okay Oracle won't look for the community to do the back Oracle will not look for other contributors in the community to take on the burden of 8 updates until at least January 2019 if not later unfortunately we are out of time sorry thank you for your questions and your comments