 How can everyone, this is the third day of the Jenkins Java 10 and up hackathon. We've made great progress the last couple of days and Oleg, I think you got our usual sort of status and such slide deck to go through. Yes, I have some slides and this time I won't forget to share my screen. Okay, just a second. While Oleg's doing that, we also have Paul from the Jigsaw JDQ project, Jigsaw. All of you, would you like to introduce yourself while we're getting set up here? Hi, yes, I'm Paul. I know some of the CloudBeats folks because I used to work at CloudBeats for a little bit. I know Kasky for a long time in some microsystems and that, so then I reached, well, fairly in the past couple of years, been working on the Java platform, a little bit on Jigsaw, but other things to language libraries and runtime. So I sort of spread myself around the whole platform. I'm happy to be here and help as best as I can to get Jenkins and its plethora of libraries onto nine and above. I think it's quite important. It's a great, great thing for you to do this effort. Excellent. So Paul, send us, everyone. Okay, Oleg. Thanks, Paul. So yeah, we will have a short hackathon intro for those who just joined the hackathon. Then we will have a co-accession with Paul and maybe other project Jigsaw contributors in order to discuss issues we heed and questions about future of Java and what we need to do to be compatible with Java 11 beyond. And then we will have a regular status update from contributors. So this is the current plan. If you want to watch this presentation afterwards, here's a link. And we post a lot of presentations in our YouTube channel so you can join and get all the content. If you want to ask any question, we also have a Gitter channel and you can just go and ask questions there. So it's Gitter.jnkci slash Jenkins. We will be monitoring this chat. So if there are any questions, we will be able to answer questions today. Okay. So, Oleg, Mandy just joined. I think she wants to introduce herself in. Do you hear me? Yes, we don't. Oh, hi, I'm Mandy Chung. I work on the JDK, mostly call libraries. And I have been working on the Jigsaw project in JDK9 and now work on Valhalla. Valhalla is the value types effort. Thank you for the introduction. Okay. Yeah, I'll briefly describe the current status and the background. Yeah, so as everybody on this call knows Java 11 comes soon and it will be LTS version. So as Jenkins project, we're interested to keep it up to date and we want to adopt Java 11. So that's why we decided to invest some effort in order to explore what's missing in Java 10 plus support and maybe fix some bits. Originally, the format of online hackathon has been proposed by Kiki. He is also on the call. So maybe he can briefly talk about the project objectives. Okay. Oh, I'm sorry. What? Yeah. Say that again? Yeah, so it would be great if you could briefly describe hackathon objectives and why do we do that? Ah, okay. I mean the same thing I said Monday? Mm-hmm. All right, all right. Yeah, so I guess the, let me see, I kind of didn't know what to do. So yeah, so in the Jenkins community, I think we sometimes divide up our work so well to the point that we don't often need to work collaboratively, right? So it's kind of looking forward to have some opportunities to bring more people together to work on the same thing. So I thought this would be a great topic and if this works out well, I'd like to do more of those. And then today I feel particularly great to have some guys from the Java team, people from Java team joining us. I think they care greatly about moving the Java ecosystem forward. And I think the work that's happening here and also the likely changes that's propagating upstream in different libraries, I think. So we can, I think we could work with them who would help us move that needle a lot. So I think it's, let's get the most out of the opportunity here. Yes, thank you for the introduction. So we started this hackathon on Monday and we already had two full days of development and actually we've got some important progress. So just to summarize the status, firstly we've got a packaging working including Java 10 and 11 releases, what packages, run guidelines and we also created some docket packages for example, for Blotion and for Vanilla Jenkins. So early adopters can try these images and get them running. And one of the major updates is that we've got a pipeline running. So there is a lame screenshot but actually pipeline was a major effort because we needed to update Jenkins course to update some plugins in order to make it working. And yeah, it's a great progress on this front because it's one of the major features and we want to make it available as soon as possible. Regarding other activities, we have posted a blog post yesterday. So you can go to Jenkins.io slash blog and you can find it on the top. So it's a summary from the update. In addition to pipeline, we had a lot of other contributors who were working on various aspects of Jenkins. Just exploratory testing and some tooling including illegally reflective access cleanup, a cleanup of built tools like asthma and animal sneaker we needed to build plugins with JDK 10 and there are many other activities ongoing. So this is the current status. We will have more details later after the QA session. And yeah, just to summarize the current obstacles what we see in the project. Actually, we've got the most of Jenkins working including all foundation features but the experience issues with development tooling. So for example, we cannot stop continuous integration for core plugins, it's work in progress but you need to fix some of our tooling and one of the main obstacles is maybe the support of Java 10 and 11 and support of multi-release jobs. So we have Devin Nosbaum and Nikola Deluf on the call. Maybe they could briefly summarize what's going on with this effort. So one thing I can say is that I've been working on not so much the building on Java 10 but the testing on Java 10 because even if we still have to build on Java 8 we really need to be able to validate that, run our unit test on Java 10 and stuff like that to make sure that we're okay with people using Jenkins on Java 10 and we don't think everything is gonna break. So as part of that I've been working on getting the plugin compatibility tester working such that I will run plugin test using Java 10 and up and then hopefully I'll have a demo of that by tomorrow. Okay, cool. And Nikola was working on my illegal access cleanup because we have lots of libraries including different extreme, Jackson and other such tools. All of them do some reflection by default and we need to clean up that. And finally we just need to build some libraries because newer versions we adopt that require Java 10 compatibility, they are multi-release so then it limits our opportunities to test plugin builds. And yeah, since we have Java experts on this call we have some questions prepared. So we reached out to Jenkins contributors and collected a list of questions we would like to ask and actually if you do not mind Paul and Mindy it will be great to discuss these questions. Sure. Kostin, is this session being recorded? Yes. Okay. Yeah, that's what you ask. Well, it's just if it's recording I may be a little bit more careful what I say. Okay. So if you want we can do unrecorded session later. I think it recordings of benefits for everybody. Okay. Okay, so yeah, then we can continue from the list. So yeah, one of the first questions from Sam was about tuning changes in Derbysch Collector. So maybe it's a bit low level but maybe Sam could clarify. Yeah, so I put a lot of work into a streamlined set of general GC settings tuned for Jenkins. We've had very good results with the G1 garbage collector. So I think that's sort of a feather and you guys is capped because you've done really good work there. I guess that's mostly looking to see what new settings are available and what has changed with regards especially to the G1 settings that we should be aware of that might want to take advantage of. I need to, I'm not an expert in the G1 collector. I know there's been, have you been doing this on Java 9 or have you been doing it on 10 or 11 PAs? Eight actually. So there's been a lot of incremental improvements going forward in G1. I don't know on the flags I can get back to you on that. There should be a bunch of JEPs hopefully or a bunch of issues through release notes you can track but I can't off the top of my head sort of dictate the incremental changes. I just know there's been a bunch of improvements to G1 to improve its functionality. But generally it's recommended Derbysch Collector for now. Yeah, it's a default one. Yeah, Mandy, anything to add on that? Excuse me. Yeah, it's the default in JDG9. So if you are getting good performance on JDK8 G1 then there are continuous performance optimization improvement in the past release. So yeah, I think we need to get back to you on the specific RIVs or work on the area. Yeah. Mm-hmm. So for the JDK11, a lot of GC work is focusing on ZGC. Yeah, it's an experimental GC. So which is even on the list to be very high performance. So basically that's the work we focus on in JDK11. ZGC, the set. So ZGC is a new garbage collector, kind of a bit like Shenandoah, garbage collector that operates on large heaps and tries to minimize the pause times as much as possible. Cool. Well, that will be exciting. That will be very exciting. So the next one. Yeah, we're interested in feedback on that if you're willing to give it a try. Yeah, why not? We already have a JDK11 packages working. So maybe we could try them. Yeah. Thank you. The next question was about the Jigsaw models, but maybe we could put it for a while because yeah, if we have a mark on the call later, we could talk about that in detail. Or maybe we can discuss it later when we are done with other questions. Yes, yeah, that's a deep one. Yeah. This is a my question. Actually, I wanted to know more about Java 10 migration success stories. So how is the ecosystem doing? What is the experience of project migration? Yeah, it would be just interesting to get your insights about that. So, Mandy, do you want to go first or shall I? Yeah, you should, yeah. Go ahead. So Mark gave a talk at DevOps UK where he summarized some of this. If you haven't seen that, that might be a useful good talk to see because he talks about that and has a bunch of technologies that have shifted. But he also asked people to tweet about this. And I think he, I don't know if he kept the archives of those, but he used that information to talk about this. From my perspective, what I've seen is technologies like Lucene or Elasticsearch are more at the front and they seem to be keeping up well. Kafka seems to be keeping up well as well. They're on, I think they're regularly testing 10 or 11 builds now. Netty is doing well. It's sort of keeping up with changes for the tracking in 11 and Elasticsearch and talk about regressions that we're fixing. I'm trying to think of other libraries. Those are the ones off the top of my head. My general sense is that things are moving forward faster than I expected. Yeah, actually it's also our experience because yeah, when we were preparing for the hackathon we expected that there will be serious obstacles to get to the things running. Yeah, our nice to have goal was to maybe get some bits of pipeline working, but actually after a few patches we get the most of the infrastructure working. So for us, the immigration was much easier than we expected so far. Maybe we can talk about that later, what you had to do, be interesting in the details to see what other people are doing. I think because we dialed back the constraints around reflective access, I think that's a lot. And based on feedback, that's something that I guess is a question later on that we can talk more. Yeah, right, actually it's the next question. Okay. Yeah, because it's a kind of major problem for almost all DevTools related projects. Yes. Just back in, I believe the tool in Maven is pretty good for most part on ignoring modules. Maven, I think is looking very good. I think Gradle is too, would that be your experience? We mostly use some Maven. Yeah. I think Gradle is okay too. They've had some issues with Groovy, but it's, as long as reflective access is still allowed, they're okay as well. Yeah. Yeah, I guess that Sam and Nicola experienced issues with Maven compiler plugin, which doesn't quite work for multi-release jobs. Yes, yes, this is, yep. Yeah, the tooling around that is not so straightforward. Okay, but we see activities and lots of projects, so it seems that everything is going forward. Okay, thank you. So should we proceed to reflection? Okay, so the question we had is about future of reflection, because in original GDK-9 builds, we are prohibiting reflection by default, and it costs a lot of issues for doctors, so then it has been reversed, and so far it's still not mandatory to comply with reflective access requirements. So it would be great to understand what other plans for the future. Okay, so, yeah, go Manny. Okay, the illegal access is still permitted in 11. We didn't change that one, so we always encourage the application developers or library developers to try to turn on denial so that to find out earlier what's happening now earlier what libraries doing illegal reflective access so that they can report to the library, authors to fix the issues, yeah, earlier to prepare when we disable it. Yeah, I mean, when we turn it on, denial. Yeah, it's what we experience, so we also did some testing with enabled diagnostics and just a second, I will find the ticket. Yeah, I guess we'll start from here and then find it. So yeah, for Java 10 compatibility, we have lots of tickets submitted from different components. Some of them are our own libraries, some of them are external libraries. Yeah, actually, this list is not complete, and if you search across the code base, you can see hundreds of set accessible calls. So what would be your plan beyond Java 11? The strong encapsulation is as we planned during jigsaw development is a good important feature for integrities to turn on strong encapsulation. So I believe it will be announced wisely when the plan is. So right now? Yeah, we have been discussing about it. I think we wanted to turn it on at some time, yeah. So I think we will wait for the, and yeah, from Mark to confirm the date. I think it will, yeah, just plan for it, yeah. Yeah, I think it's to be determined based on feedback really. I think that's an important part is getting feedback from the community to decide when to ratchet this up and to what extent, whether it should be done in one go or done intuitively because you can sort of increase the strength of it in grades. So I think it's to be determined, and I think it's dependent on the reactions in the community and if major libraries are ready or not. Hi, can I ask just related to that? So with projects like Elasticsearch, Kafka and Netty, do you know if they're running, are they just ignoring reflective, the illegal reflective access or have they resolved them? Now, I know about Netty more than others. I suspect Elasticsearch seemed to be with you, I think who's on the open JDK list talking regularly. They might have done this because they're very, very strict in what they do with Netty. Netty needs to go into the internals of the JDK and they can operate without unsafe access if it's not there and they fall back in slower mode, but for super speed they want to go into the JDK so it could take a long time to get them off, say, the unsafe thing, which is a slightly separate issue. We have provided APIs that do certain things that they were using reflective access for, but I don't know if we've got all of the reflective accesses out of Netty yet in that respect because when you want to use unsafe, sometimes you need to use reflective access to get access to, so there's a chicken and egg there, but we're not going to pull the rug from under Netty and libraries like that until we've managed to resolve all the reasonable use cases in my opinion. Right, and regarding ConSafe, the plan is to remove it in Java 11. No? The plan is to remove unsafe when we've reached safe, supported public APIs for all major users, and that could take a long time because some of the use cases that people use unsafe are for what we're working on projects like Balhalla for value types, or Project Panama for better native interop. So these are long-term investments in the platform, and until those get integrated into the platform, people will still need to use unsafe for things. And in some extent it's a bit of an arms race as we produce these new features and then other people want to push the platform even further. So if you want to peek and poke at memory unsafe is what you've got, and there's always some strange use cases for doing that. The question is whether we think those are reasonable use cases or not. So it's going to hang around until we can, at least Project Balhalla and Panama come through and maybe some other projects too. Okay. Now I think the thing is we have very clear guidelines on what this is now compared to beforehand. A bit of a we couldn't enforce or we couldn't even talk about these in a reasonable way because we just couldn't control access. Okay. Thank you. Any other questions to go on this topic? I guess I would be kind of curious what the proposal is for replacing use of reflection in, for example, some of the serialization libraries and other things that are kind of dependent on access to private fields. So the access to private fields we're really dialing up. If we're just talking about the class path, we're really restricting access to stuff within the JDK. We don't want people, we want to try and restrict people poking around and into the JDK internals because it limits what optimizations we can do and it limits how we can change the internals going forward. So that's the primary focus. When we're dealing with modules, there's other ways to express that you allow someone to do reflective access to you. That's called open modules. That's a whole different discussion but we're primarily, and Mandy can correct or confirm, we're primarily trying to get people from poking around in the internals of JDK. For example, extreme poking around in tree set or tree map to do some optimization. It does some pretty, if we refact a tree map, we've broken extreme. They don't know about it and then the libraries that use this find this out through all sorts of means. I think it's tree map. I can't remember exactly. Yes, it is. It is. No. It's extremely... It's extreme. It's right. So the libraries that poke around reflectively in other libraries outside of the JDK, that's still fair game. When you create a module, you may encapsulate your internals and then you can decide from a module whether you want people to allow access to you into your internals or not. I think if I understand it correctly what you're saying basically, it's going to remain open when you explicitly use the open modules option for non-core modules but you're trying to protect the Java internals from being... Someone decided to go reaching around and rearranging things as they please. Yes, because there's... When the hotspot compiler has certain assumptions on certain layouts of classes like for example string, we changed the internals of string so that it actually is a byte array, not a char array, and some people poke around in string and now that will fail. But we've made some optimizations in string called compact strings so we use less memory for TFA to ASCII strings. There's other areas in Java langen with method handles, there's optimizations around final fields and stuff like that, so if you start poking around in the internals you could actually start messing around with the assumptions on how the JIT works and how things compile and you may get unexpected results. We've certainly had that problem with the JITGINS pipeline in the past. We know your pain. Yeah, I mean, if you're poking around internals because you're working around a bug or you need another API point this is what we'd love to hear about because it may be able to provide public support for use cases that aren't available at the moment. There are certain cases that are harder than others. For example, people want access to the address of a direct byte buffer and that is obviously... Once you've got that and you pass that around, that is obviously unsafe. But Netty is an example of why it wants to do that. There are other use cases too but there are less impactful use cases as well. In our case we have class loaders direct access in the core because the Jenkins has class loading support from plugins, so we do some tweaks in order to get it working. And yeah, there is also class loading cover remote channels, so we can download classes. Yeah. We'd be interested in those because we have added some features in 9. I think Mandy can talk more about that. Yes. For class loading, one use case we found is people like some libraries are poking to define class field of class loader. They don't have the access to the class loader hierarchy, the class itself so they cannot extend to it and they define the class. So what we added in 9 for them to replace is lookup define class. So you if you can securely get your lookup to define a class in your runtime package of the lookup class, you can use this new API and we also add in the lookup class API private lookup in if you have the access to your module then you can access to a private class in your module. So we try to provide a secure way allowing you to achieve the use case you want to have. So your advice would be to create a multi-model jar to keep the current usages for Java 8 and to adopt new APIs for Java 9 and beyond. Right? Yes. That's one option if you want to deploy one single jar that runs on 8 and 9. I guess it's our use case. By the way are there any replacements for the find class method? Because today on the morning we had a call with Tracy when we were trying to resolve one issue and we finally got to find class method. Which is exactly the same background case. We have to understand the use case. This is the first time I hear putting into the class or the find class. That's exactly what we want to do to provide the illegal access warning message so that you know you are effectively accessing some private method. We want to hear from you why you used that reflective access and what we don't have in the public API to achieve that. You should also file a JBS issue so that we can follow up. Maybe it's better to take it offline because it would be deep dive. By the way, there is an existing lookup find class method. I'm not sure whether that satisfies it. Lookup find class. Lookup is a class. Find class is a method. I can fix that up with you. Thank you. It's something we really need to consider because it's just logic of Jenkins. Any other questions about reflection? If you want to ask the questions during the call, please feel free to just propose them in the bottom. We'll try to reach them. Let's move on. Another question I heard was about Java EE models. Currently Jenkins Core depends on the Jax B. It means that we use some models which have been removed from Java 11. We found our way around in Docker packages and we know how to approach it in work packages but it would be great to get your advice how to properly handle such cases when we want to keep releases compatible starting from Java 8. We're removing the Jax B module from Java SE in JTK 11 should not impact the dependencies I mean your Java dependencies on it. The changes you would need is to put download the jars and put it on module path or class path. It's what exactly what we do. We have posted guidelines about running Jenkins with Java 10 and Java 11. It's here. Here are the guidelines. We recommend downloading these libraries. And for Docker packages we also have these bundles. These packages don't need to do anything. The problem for us is we would like to include it to the Word file directly so our users don't need to do all these speeds in order to get it running. Are there any standard ways to do that? One thing I think of is that might not be an ideal way for you is to create your custom image. That's one option for you. Create your custom image that link in your modules that you depend on. But obviously then it means that the users will need this custom image. We will need to somehow ship it to the part of our Word file and then unpack a sheet which will be unlikely to you. It works better in Docker model. In Docker we just package whatever we need. Yeah. Okay, thank you. So in our case we have some flexibility because we run with several web servers and since we have Jenkins plus loading from plugins we have a choice to upload these libraries to a particular plugin. So using Jenkins tooling we have a way to approach that. But if there are any other standard tools it will be great to know. Since this is the area that I kind of talked on the challenge for me if you think yourself as a web app developer you're writing a Word file and you're thinking about using JaxD or some other option or JavaE module in there. Now this Word file can get running also to different environments. If you're running in JavaE if you're only running in JavaE it's great because you don't need to expect that to come from the platform. It will be there, yes. But then we also have to run on a standalone tablet container which does not have these guys. So that puts us to the Word file developer in Japan. In the past I feel like we've basically kind of came down to just bundling those JaxD where we live and then kind of hope that they have the container to be able to recognize or the JaxD API in this case so that we can correctly review with this two different versions of two different kinds and then to poke around that space. Well, that seems to be their going practice but can we do better than that or are we doing wrong? I can't we don't provide any help in the platform to try and make that easier. I think the assumption was that you'd be in some EU compatible environment I guess from that perspective. You're kind of having to do probably class loading tricks or something like that. Didn't you do that already to try and work around the JaxB version that was distributed in the JDK if someone wanted to upgrade it to a newer version that you had a class load of world? Your own class load of worlds thing, didn't you? Yeah, I'm trying to remember that because we both used to work in Java and this guy is kind of saying that we built in the past but they don't know. This is kind of a similar problem to when because JaxB used to evolve so slowly in the JDK compared to JaxB outside and people would want to distribute their own versions to override it and that's the problem is it's problem overriding it. It may be there, it may not be there you're sort of dealing with it, it's sort of expanding the problem out to something that isn't there. I'm wondering if fundamentally the same problem? Yes, I think it is the same problem. So I guess the answer is there is not a basic problem to help with that platform so we're going to keep doing what we've been doing. I'm sorry about that what we tried to do when we were in preparation for the removal was make sure that they're not there by default when you run it so that it highlights this so it gets people used to this and then now, that was in 10 I believe and now in 11 they've gone to Jakarta EE Isn't that right, they've gone to that environment to be maintained further Yes the upstream project I mean this may or may not exist we'll continue in the Java 10 because the Java EE will contain Jaxby without the container one I expect it will, I don't know what they're doing in terms of profiles I haven't really been tracking that but you could imagine a profile without Jaxby as a shrunk down minimal profile That's true Cool, thanks Okay, thank you maybe we should pick some questions from others and then return to my questions yeah, I've submitted a lot of them but yeah maybe we can return to them later one of the questions was from Denis Dekter what would be the replacement of some MISC signal I don't know yet we know that it needs looking at Oh, it's going already it's still there some MISC and SAFE is in the JDK unsupported module so this the module also includes a couple other APIs that we know some library depends on and we are critical some MISC signal is one of them yeah and we have an RFE we the call library team has been looking into the replacement API for it but we wanted to get more use cases it seems like for example Wi-Fi use on MISC signal at one point but they they are able to remove the dependencies one use case we found is like control C they want to intercept a signal and handle it things like that so it just depends on the use case so far we do not really see a high demand on this but your question is still supported in JDK I mean it is still available as an internal unsupported API in 11 I guess that's the guy who added this part of the code originally where I was coming from is like I wanted to write the program that behaves and feels like a normal in a Unix program and then in the Unix LAN the signal these are kind of important part of the ecosystem for example like you send the signal after you download the configuration stuff like that you know in a way the way I think of it is the fact that the Jenkins is implemented in Java is an implementation detail for the developers something that I didn't want the users to care about so that's the kind of I mean if you ask can we work that around it's yes like you know we can even drop it and it's kind of not the end of the world I suppose but it sort of moves us a little further away like this system Java behaving citizen and that's sort of like when people hate Java we have to overcome some objections on the behalf of the users we have some hostile feeling to Java and then this is not behaving like other tools in there at least one of that we get that it's still in the unsupported module and it will still stay there until I think we can work out a use case Andy is right, it's kind of something that's not as heavily used as others in the unsupported module but it's used enough in some areas I think we kept it around until we can work out something I mean the problem we have with some of these cases is that we have Windows, Mac variations of Unix to support Java and often the challenge with these cross-platform things is Windows and getting that it's getting better and some of the challenges you have with file access and stuff like that is Windows and that's one reason why it takes a while and then people come out and say they don't care about Windows until they deploy it on Windows so I know it's predominantly x86 in the cloud and perhaps at some point we need to recognize that it's a predominant platform we have recognized that in some cases for example by adding DirectDio support it's predominantly an x86 feature a Linux feature I believe and it may not work it may be just disabled on Windows the question with signal is it's pretty fundamental so that's why it takes longer I understand I've been breathing so another area we're looking at in terms of systemy Java if you like better is project Panama we want to get better at interoperating with the platform and interoperate with native I'm a great fan of having kind of like POSIX support JRuby does that well but we think with Panama we might be able to get closer to POSIX support and it's interesting to see where Azure is going with Windows and it seems that Windows is moving do you think it's moving towards that direction I think they're trying to see how critical it is so project Panama may enable that better it may enable better signal operation as well better native interop to system calls and faster native interop as well but that's longer term we hope to make some progress on project Panama going forward with better native interop quicker but it's going to take a while to get fully verified sorry let me just go quick when you talk about trying to understand the use cases so if we've got specific use cases for signal and let's say we're using the alarm signal and we can describe the case what's the best way to sort of communicate that with your team yeah you could send it to call library call it step that's one thing I can send you the JBS issue number that we keep track of all this information I think why I ask for use cases there we look into we look into an API to support the POSIX like signal handling a more generic one thing but it involves interaction with the VM VM also have the handlers for various signals so we have to come up with an API that I'll define it yeah it's kind of very tricky to define an API such a generic way and whether it's synchronous or asynchronous is another factor to consider so if we know only specific use case rather than generic signal handling then it might be faster to come up with an API specific for that so right but I hear that well generally the POSIX signal handling is something that is good to have a cross path from implementation in Java and I can send you the A-list and later on yeah for NWK thank you thank you very much so should we press it to other question go for it okay thank you so yeah Stephen Connolly asked about National so it's scheduled for deprecation and it will be great to know when it may be removed because we have some logic dependent on that and if it gets removed what would be the best replacement yeah so yes it's being proposed for deprecation but yeah it's out there and we're getting some strong feedback from that and there's no time frame yet as to when it will be removed and that's to be determined and what we're trying to gauge is whether there's community interest in taking over maintenance of this project so that's I don't know if anyone has stepped up yet or is interested in maintaining it outside of the JDK and that is one way of deciding what happens in the future is whether there's enough community interest out there to maintain it a bit like JavaFX because that's going out from the JDK but there's a set of interested people both companies and individuals and open source interested in maintaining this going forward and I'd be interested if there's enough interest and that's one to do the same if there's not it's likely to get deprecated and then removed from the JDK and this will be there somewhere so one alternative is it gets picked up by the community the other alternatives are Graal I don't think there's any official announcement from us on what an alternative would be at the moment but so far if you want to migrate we should consider this that's one option another option as I said is sound out whether there's enough community interest it's even doing something that's normal that's more I don't know what does it know yet oh yes so what is he doing oh right right ok unfortunately we don't have him on the call so yeah for him maybe we could follow up with him yeah let me try and dig out a link on the discussion I can't remember where this discussion was on let me open JDK JDK dev list I believe the dev list here I'll send the link in getter this is a C freds or discussion deprecation so one thing that I think is being decided or is was that Nasshorn depends on a library called Dynalink and originally Dynalink was proposed with Nasshorn to be deprecated but the original engineer who did Dynalink he's not an oracle anymore but he said he's willing to step up and maintain Dynalink so that's something I don't think is going to be proposed for deprecation at the moment one thing about Nasshorn do you use the EPIs or just the scripting engine that's one thing as far as I know on the scripting engine right okay because the scripting engine is looked up through a service provider interface yeah basically Nasshorn itself is a service provider I think that will give you do not depend on the Nasshorn API which is good what it means is it's easy to replace a different service provider implementation if you want to I'm going to post a JVMLS thing if you're interested for Nasshorn just from a technology point of view this is an alternative let me open this link too many windows open that's a presentation by Jim Lasky the original architect of Nasshorn who talks about an alternative approach no plans on whether this is going forward or not it's a prototype and investigation you can see where we might be heading with this or not if you're curious about how to integrate alternatives into the JDK okay thank you later we will follow up and add some links to this discussion okay so we have something like 5 minutes left for Kui actually we have several other questions one was about JVMLS start removal then there was a question about quality outreach program which maybe we should start from this question because it seems to be a question we may follow if we continue working on Java 10.11 support it would be great to have your insights how the program works and which benefits do we get and how could we contribute and how can we get contributions so we get a win-win solution let me just if people don't have to run and upon maybe I won't continue answering more questions there's nothing that says we have to start at 10 we don't have any blockers I've just decided to pick one question and then to talk about others whether we proceed okay I'm happy to keep going if people find this productive and useful yeah it's definitely useful thanks for your time anyways continue so quality outreach what your question is yeah so our question is yep so how do other projects collaborate with quality outreach program and what are the success stories there yeah I'm not this is something I'm not very familiar with it was Rory O'Donnell who was doing this work and I think you need to reach out to him to get details like I'm sorry I don't know enough okay it's perfectly fine or at least we have a compact so then maybe we can follow up on that later okay thank you okay so if we continue from the top one of the question we have is java web start removal because we have java web start being used for Jenkins core itself and for Jenkins agents it's a remote builder which connects to Jenkins and does builds so it would be great to understand how should we press it there okay did you have any comments on that I don't have any comment on that okay so we're it's going away it's it's a tricky component to secure not going to do much detail so it's something we would prefer not to support going forward and so you need to I don't know how I can't remember the various master to slave communication mechanisms you have this is one of them isn't it yeah so the video side the kind of user experience that this was aiming for is like something yes I wanted on some platforms where like a windows main we used to do things more from the GUI and I wanted to let people just click a few times and then be able to use those computer for build it web start from there to be back then the handy way of starting a java program without going too far yeah so yeah so the fallback I think the current fallback is just we're going to have to ask people to open the command line and type java and download some files and stuff like that so it's not the end of the world but it's certainly a regression usability yes I understand that we have ways to let people still click around a few times to have a program it's important your use case is great when there's trust involved in what's going on but when you don't have trust and applets and all this it's a really hard environment to secure and it's something we're trying to move away from in terms of distribution of applets start was a key part of yeah right the hope was we are not using applets yeah so or maybe like I said that dotnet the equivalent would be like we ask people to download the executable and then they can double click that and windows pops up some warning like hey download the program that's not a good idea and if I say yes then it still runs I guess I know in java 9 there's an 80 better an 80 packaging of java program could that be somehow you mean a jlink you could certainly jlink your own distribution of a java slave thingy but that would still need to be downloaded explicitly so you could decide to package the whole 80k plus bits you need to communicate as an image and you could put that in a docker image if you wanted docker gives you an easier way to bootstrap the process or not depending on the user capability for that you could certainly experiment that way so everything is nicely packaged and bundled as one sort of jdk plus bits you need and you can shrink it down to what you need so you don't need to distribute it with what is it I'm trying to think of other packages and NASHON for example if it's still there you don't need to distribute with that I mean you pretty much need java base plus the slave dot jar or whatever it is but a lot of dependencies come through your emoting and you lay down the jars of your dependencies on your emoting so the slave is like a shim just to conduit to push other dependencies down so you can probably get away with quite a minimal runtime here's an experiment I'd be interested in you could even try the growl runtime to shrink down that to an executable binary and shrink down the size of that and speed up the startup time of that is an experiment as a separate thing but it allows you to do that kind of experiment if you don't pull it and we have all tooling in place so yeah what I've written it could be a great idea for this hackathon so if somebody wants to try just package and promote increase jailing and see how it works yeah you should shrink it down you should go down to what's the size of a jailing Java-based binary Mandi I can't remember what it is I cannot remember and at that time I cannot remember but it's much smaller than the entire Jerry it is not as small like because of the VM only the biggest piece there is there's VM with the full blown features like JDMTI and others I could view it and then find the numbers I'm trying to find the slides just if you're curious it has been a while one other thing you might be interesting in is the Java Packager JAP that allows have you used Java Packager or are you aware of this that allows you to well it might not be completely relevant but certainly it allows you to the Java Packager will build a run time image for the application package it's a more user friendly tool for normal applications sounds interesting it's a JAP being draft right now it's spelled JAP JAP like our JAPs so in this project we also have JAPs I'm just saying are the Japanese as well so it's pending JAP it's not accepted so far yes and what would be your recommendation about existing Java Web Start tooling should we remove Java Web Start from common packages taking your concerns I think you should prepare for it going away in that sense something you tell your consumers or users that this is something you should not use going forward my opinion it makes sense and we want to detach all this functionality from the core move it to a plugin it would be a first step towards the deprecation for us yeah okay, thank you okay should we move on so it's a rather generic question are there any other incoming changes in Java 11 we should consider so for example if you open change log you may see lots of changes and I use selector logic since we heavily use this logic for example for remote communication it would be nice to get your insights to which issues should be prepared and how should we test upgrade to Java 11 when we get to that so some of this some of the changes in there not just selectors I believe are for preparation for fibres so what we're trying to do is create lightweight threads and we need to make sure that the underlying infrastructure is effectively non-blocking better non-blocking than it is and these are just implementations not changing the API and Netty's been keeping us honest if you say or keeping us so that it functions on 11 with these changes there are very edge case areas where the compatibility is a bit sort of uncertain and Netty's found these cases so I hope that Netty is strong enough for use case but you won't be affected by these internal changes there has been some API enhancements proposed I don't know if you're tracking those around let me see there was some API enhancements around where was it callback based selectors is that something you can look on the Neo on the NeoDev I'll copy into the the glitter let me just so NeoDev for thread on for callback selectors I believe that's the most thing I'm aware of on the API side otherwise it's internal details so if you can get to 11 and test with the latest EA builds that's great and report feedback early then we can fix any behavioral issues I did some testing on Monday so I can confirm that agents are able to connect and use NIO on Java 11 obviously the devil in details so when we get to whatever kind of load testing maybe we'll hit something but so far it looks good yes net is a great use case for this given how it's deployed at scale the another area it's not just related to not related to NIO is HTTP clients there's a new HTTP client it was incubating in 9 and now and 10 and now for 11 it's going to be a fully supported API it's much better than HTTP URL connection which is a train wreck of an API in my opinion and it scales as well it should be it has very good asynchronous implementation underneath it might be something you're interested in so when we get to Java 11 probably we can remove other five or so different HTTP client libraries we use within the project I hope so it may not support everything it's pretty minimal API so you may find you still want your Apache HTTP client features yeah our infrastructure is distributed so we have thousands of plugins and your plugin developers pick other APIs for this project you commonly can find almost every library existing for Java and it applies to these things so these kinds of generalizations should be really helpful yeah I mean if you have any feature requests or enhancements you'd like in this area we'd like to hear about it as well does anybody have any such requests we'd have to look into the APIs and see what we're using from all the different libraries and see what we need maybe not a request so our ask would be to remove static methods which allow adjusting settings globally because in some cases it's a huge problem yeah yep I don't know how we can remove those configuration of HTTP URL connections yeah just default proxy or default host validator so whatever they're not great they're great yeah okay I have the number for the glink Java based image I was playing with it on macOS I don't have a Linux box on top here yet so the entire jre macOS is 214 megabyte jdk10 Java based only is 23 Mac it's a little larger than jdk9 I think because we are adding features but in the modern world it's a reasonable size yes which is good I think if you stream build your custom image just include the modules you depend on and then compare the size that compares very favorably to the minimal java docker images out there yep yeah that's right speaking of java docker images I had one question actually about time lines etc. for java 11 docker images so the story behind that we had hit one regression with the latest release available in docker we know that there is a new release and davin has verified the bug we had and yeah so he verified this bug was about manifest retouches and he confirmed that it's fixed in a plus 18 release so the question was when should we expect it in docker and how would we request these releases if needed I don't know when it comes into docker I can't remember what the EA release schedule is in our jdk but I have a problem with open jdk or jdk images on docker hub I don't know where they come from when that docker hub there who is that produced by also by some third party yeah so in this case it's probably not trivial so docker itself as a company maintains a bunch of images from what I see he references docker community things so likely it's an image shipped by docker as a company yeah and where did they get the open jdk builds from I think docker hub in general has a trust issue personally I wouldn't trust anything in production from here in my opinion while docker hub speaks for itself anyway that's a separate issue but I expect once the 18 EA build comes out this will cycle around but it's not us who control this cycle around because we don't produce official docker images yet it's something I do but it's not something that I can control the production of I wouldn't say we would not recommend yeah I wouldn't put that in I don't want to prescribe what people do here this is my personal opinion okay and what would be your recommended image I would get the images from open jdk the GPL if you want open jdk I think someone's getting them anyway and build your own docker images that's my personal opinion if you're going to distribute your own docker images so you conserve them from your own area or you increase the trust of what these contain I don't know this is coming from me who doesn't have a lot of experience in the container and docker world and how it operates I can't remember what the schedule open jdk ea builds are I think to some extent it depends on whether the tests are passed well it's weekly it's weekly yeah in this case particularly the build available from open jdk has the fix it was just the docker image that was out of date I see right and the build 18 is already out in open jdk so yeah like in this case we'll just need to wait while we ship experimental packages and when we go to production we'll need to think how to approach that have you got any experience running Java in docker containers and we have improved its operation in there but do you have any feedback on that so for me it just works I don't care much about performance and it works but yeah for example Sam van Orert he was playing a lot with Java optimizations including so maybe he has something back I would say that my experience with Java and especially Jenkins and docker has generally been good the only quirks I've seen have to do with specking out the Java instance running within the container is allowed to use resource-wise and I think a lot of that has been addressed now yes I have really nothing bad to say about it so that's good feedback yeah thank you it should just work and it hasn't been in some cases but now it's getting better with one catch which is attaching bugs to to Java instances running a docker on Mac and I think that's a Mac specific problem rather than a problem sometimes it just fails right really it all for me but I'm running kind of an old for docker on Mac I switched to Linux if I want to use it in the container I see so actually I use it more to debug the docker and Java a lot so what I hit actually today when I was presenting development flows I tried to connect the debugger from IDE to my Java 10 image so we have all flags so we just start with common flags and what I hit that IDE fails to connect with strange issues so that's why I thought that after it's the same as Sam was talking about but yeah that's the other one Visual VM has a lot of issues with the connection if you're like I said I usually just boot it up in Linux on my personal laptop if I need to for profiling or run it outside of the container sounds like a networking issue yeah that's the way it reads I think it's something with how the networking is set up specifically in Mac and the way it's passing the ports through okay so just to them I started the image I used the wrong port but it shouldn't matter for now so yeah when I connect a remote debugger with Java 10 for me it just fails yeah it's something like that handshake failed connection pretty much is really closed but if you take a look at the image it still waits for connection without some wire shark and some docker debugging going on in there it's very hard to know we haven't investigated so far to report but I will continue that and if it's a release I will report that most likely my ID is just outdated or something like that so I have to I'll leave right now so thank you for inviting me being here thanks a lot Mindy for your help I'm much appreciated thank you so actually we ran out of questions but if you have questions from your side maybe we could try answering them I do see one question on Gitta from Sam he asks if we know roughly what JDK versions project Panama will be landing in or is it likely to be spread out several so we don't in general we don't target to release until something is we think something is ready but what we given that faster release cycle what we try to do is to take a large project and split it out into smaller pieces so we can deliver value sooner and that's a hard challenge because you don't want to deliver something sooner and then it becomes broken or outdated or wrongly designed to the larger picture so we do have to balance that so we don't have a targeted release for Panama yet that's all I can say about that we're just operating on in the Panama repo trying to get a minimal foreign API as we call it and when we're happy with that minimal foreign API in its minimal form and it fits well with the larger picture then we'll be confident about targeting it that's helpful that's definitely helpful there's very active progress on this API in project Panama at the moment so are we looking with the outcome of that sort of a to have job in the state sort of like Python where it's very free to accept native code libraries were needed for specific purposes the idea is say let me think of an example say we want to integrate with the Open or Acuda or OpenCL GPU so you should be able to take the headers and run it all over it to generate Java interfaces which describe the methods and structures and then at runtime you can bind those interfaces and data structures so that it calls directly through to that library and so you need a notion of how to map the C or C++ model into Java with reasonable accuracy so basically that takes away the bootstrap by hand you had to write a whole load of Java, JNI, and Java and C or C++ integration and that's very error prone so it takes away the it gives you a huge bootstrap into interoperating and as part of this API we hope to improve the speed of the speed of JNI because there's often a cost to going to the native boundary between the VM outside and we hope to optimize that as well. I can see why that's a very exciting thing for the overall Java ecosystem in so many ways. We want to use it ourselves internally too so when you bind to an API it will actually bind it to a particular platform it won't be cross-platform it's up to you because different header files on different platforms will have different ways of expressing this it's quite subtle sometimes it provides you that layer and then if you want to go layer above you may have to write your own interoperable layer above that depending on how cross-platform header files are but when you're dealing with certain platforms they have certain assumptions on layouts so when you're binding natively you're often binding closer to something That's great. In this project we have several libraries using GNI for example for Windows Process Management having such tooling would help us a lot because even now for simple libraries it's a nightmare to maintain all communication It almost sounds like some of the new APIs that are being talked about for operating system integration I mean that we don't even need to resort to this interface we may give this out of box which will be a very exciting time for us Maybe I promise I hope we drop 32-bit support by this time Yeah, I mean 32-bit support is we don't support 32-bit going forward now I believe I don't like cross-platforms It is supported by others maybe but not by us going forward I think we've effectively dropped it Yeah, there are such discussions in the Jenkins project but we haven't came to the decision yet because we still have a lot of users running 32-bit Yep Okay, so thank you. Do we have any other questions? Let's get packing He's been doing it constantly Okay, so thanks Paul Should we do She's out there Thanks everybody who participated or who watches this video online. If you have any follow-ups just use hackathon channels so you can just reach out to us in Gitter or in developer mainly please and we will follow up If you have any questions just raise them here I would like to get a follow-up on the GST flags and new settings but I don't know what the best channel would be for that The best channel would be hotspot dev if you want to ask questions there but first maybe let me follow up first try and get some information from this area and see if that's sufficient and then you can follow up if you need more questions Okay Okay, sounds good Yeah Thank you very much Should we do a short team sync up as a part of common update or should we just go hacking? Let's go ahead and make going we've got an hour and a half here lots of interesting information unless anyone has a highlight So no highlights from me Yeah So I guess our pain point now is development to link so maybe Sam, Devin or Nikola have updates on this Right Yeah, I'm still wrangling with the annotation processing I've traced it down to something inside the Maven compiler plugin and how it's discovering the annotators but it's going to take some time to unravel this one I'm afraid Alright Okay, any other updates? Hi, I've been hacking on the Jack Speedy Thank you Any updates on power? No update from me Hello, no updates from me I just I'm going forward with the tests I'm doing I'm updating my ticket Hopefully get all the pipelines green by few hours Cool Okay, I guess that's it for today, so we continue hacking and tomorrow we have a sync up session so we will check what's the status and yeah, that's it for today I'm stopping the broadcast and thanks again to everybody who participated Thank you so much for inviting me Thanks a lot Paul It was a really helpful session for us