 So welcome to this first talk where I will present in the Eclipse IDE and what we're doing in the project. It will be a high level presentation about the project. It doesn't show too many features. It shows a little bit what we're working on and what the community like, assuming that you're not yet participating in the community, at least some of you. My name is Lars Vogel. I'm an Eclipse developer. I'm also in several other positions within the Eclipse project. I'm not getting paid for my work on Eclipse, so it's basically fun and free time and investing into a great open source project, which I like. So let's see. The Eclipse project is hosted at the Eclipse Foundation. And the Eclipse Foundation is a legal body which helps the Eclipse project but also other open source projects to be successful. The Eclipse project was the first project the Eclipse Foundation has, so the name similarities are because it was the first and only project, but the Eclipse Foundation hosts several other projects as well, I think 200, 300, I don't know, in all different areas. This talk is only about the Eclipse desktop IDE, and of course then we have what we call the top level project, which is a narrow scope of an IDE for Java development and Eclipse development and all the other projects. And this is a statistic here from the last three months of activities within only the top level project. So the top level project again is just a Java tooling which you may enjoy or not. And I like to show this graph as it's again the commit statistic of the last three months because it shows how healthy the Eclipse project is. If you look at the individual contributor statistics, we have a few people like Alex and who are doing a lot of work within the project, but we also have a lot of people just delivering a very small patch. So this white area is not a graphical error, it's just a lot of people just providing one or two patches, bringing Eclipse forward, maybe fixing a bug, which is annoying for them. You also see if you look at the companies involved that we have, a lot of companies involved, Reddit, IBM, Voguella, GMBH, but also a lot of people not directly associated with the membership company or not even having committer status. So I think unaffiliated committers and contributors make up to 40% of the project. So it's a really nice open source project to be involved in because it's not only the IBM anymore which drives the top level Eclipse project. If you go back five years or six years or eight years, the core of Eclipse was basically led by one company, IBM. They made all the decisions, they make all the development investments, so it was fair that they were making the decisions. And it was hard to get involved because you were not part of a team. So patches were not reviewed or ignored or suggestions, they may be not applied and so on. And I think it's really nice that we over this, we also have a diverse leadership team for this top level project. So we have Alexander from Reddit, we have Myself and we do have three people from IBM. They also had represented it from Google in the last year. And it really helps moving the project into what I call a real open source and not a company dominated open source project. The role of the leadership team in the project is to set the guidelines for the rest of the developers. So if a developer develops something and nobody disagrees, it just goes into the code. But if there is some disagreement, they may bring these issues to us or to the project lead and later to the leadership team. And then they may make decisions for the whole team. For example, the reason we had the discussion should we accept code cleaner patches. There was a few developers which were a little bit concerned that that will affect the Git blame functionality. So see who has changed this line, what commit. And there were two sides, some people wanted to clean up, others wanted to preserve the history. They brought it to us and we decided code cleanup is more important than Git history. We don't want that code. As a direct result of Oracle deciding to release Java every six months, the Eclipse project decided that we release every three months. That is also a little bit the result of the fact that the Eclipse Foundation believes that it's legally not possible to support a better release of Java. So if there is Java 12 in development, there are legal things which prevents Eclipse from providing an official build where Java 12 is involved. So there are always these tricks that you get a feature patch which you can install to still work around this. But as we may not hit exactly the deadline of the Java release, at least you don't have to wait very long time before you get the official Java support. So this fast release cycle enables us to work to support you 9, 10, 11, 12 once it's out. The question was, wasn't there supposed to be a rolling release with Eclipse? We do have daily builds of Eclipse, but we put a little bit more effort in testing before an official release. We also have a cool down phase. It's now only two or three weeks where we don't develop new features. We focus on testing and so on so that you can enjoy a stable release. But I'm using the daily build, of course, and it's stable and fast. We also, for example, it enables us if a new JUnit version comes out to support it. We also dropped the silly names. You're not silly. Some people love these names, like silly people like Kastner, sorry. But the issue with the namesource is that not all people could remember them or pinpoint them to a year and I'm one of these persons. So I have no idea when Luna was released. I have basically no idea when Master was released. I only know it's very old. And our customer also didn't get any indication that we were using a very, very old Eclipse. So people were saying, oh, my Eclipse is so slow and bad. I switched to another ID, which is not what we want. So we moved away from this naming scheme and now we have year and month like Ubuntu has. So let's say in 2023, if you start your Eclipse from 2018, you feel like you see it on the splash screen and maybe you feel, oh, I should update. Maybe the thing says involved in four or five years. So I really like that. Kastner doesn't. So I think we're doing well. We're getting faster every three months and release. It's also very motivating for the team to work on stuff or for contributors and other companies to contribute. Because if you do something, you don't have to wait a year in the worst case to get it into an official build. Maybe you only have to wait in worst case scenario three months, particularly a little bit faster. So that's a little bit for organization. Of course, we have priority topics. So the development team likes certain things to work on. And definitely one of the topics is performance instability. It's, I think the last two or three years eclipse has been significantly improved in performance. The worst release was eclipse Mars. And yet I don't remember when it was. I think five or six years ago, but Mars was horrible. It was slow. It was buggy. It basically a lot of people actually started to dislike eclipse in this release. There was some reasons for that because it was a completely redesign of the underlying framework. But ever since the team has worked on this. And I think I remember Jonas last year trying out the latest releases. Whoa, this is really fast. And we're trying to do this with every, every release. There are a lot of small things. For example, we're switching from synchronous layouting to asynchronous layouting. Not, not stopping the UI just and waiting for some, some better path. Removing old that code, maybe checking for a compatibility thing, which has not been there since 10 years and so on. And that really speeds up the whole thing to give you an example. This is my email, Gmail, which I now refresh with F five. And at the same time, I'm starting eclipse. It email refreshes a little bit faster, just a little bit when, when starting my eclipse. I'm not sure what Google did. It used, Gmail used to be lightning fast, but we introduced this, this splash screen. And now every time I hit F five in the browser, while reading my email, I said, oh fuck. So eclipse now starts almost as fast as I can update my, my Gmail browser. We're working on it to make it faster. Maybe Google also wants to make it fast again. I don't know, but very nice, like a few seconds. There are other areas of improvements. For example, Reddit is now working on the Maven tooling actually together with a patchy project to bring in much better Maven tooling support. Also, the Git tooling has been super fast these days. They're basically doing everything asynchronously now, not blocking the UI anymore. So it's really hard now these days with the latest Git support and it lips to get a UI freeze from the Git to tooling. There will be more on performance. And I think I have a slide on that. So Kasten will be talking about what the project did in the past to improve this performance. He showed basically how, how we worked and so on. So join this. We're also trying to give you better and asynchronous code completion. At the moment, code completion in eclipse in most cases is synchronously. You have a lot of Java files in your class path. It can be that code completion blocks the UI. This should be gone once these patches go in. We also have code completion in places where you would expect code completion. For example, the first workspace selection dialogue. You can now have code completion to select the path you want. And we want to introduce this on several other places. Also available since last release is an option little bit hidden. Details on the spark report to remove the big lock while building your workspace. The current default way of the Java tooling is you have, let's say 200 projects in your workspace. And you say clean workspace build all. It basically locks the workspace and you cannot work in parallel or anything while it's building. Again, from a redhead, there's now a possibility to set the locking rule. And you can set it to project for example. One project is built by Java tools and you still can edit unrelated other projects. It will be a little bit ironed out and hopefully be available also via the user interface. So very helpful for big installations and big workspaces. Now also we would like to improve the usability of eclipse. And one of the things which has been introduced in the last release is code mining. This is basically I think the idea stone from visual studio code. It is the idea that you add information to the text editor without of course changing the text editor, which gives information to the user about his or her code. So for example, I see now with this code mining which is not in the text editor at all. It just displayed here that the table view is actually referred to five times. And I can also click on it and I see the references. It makes it much easier to find public methods which are not used anymore. So you have a public method. You basically have no idea who's using it. Now it will go through your workspace and show you for the methods if they're used or not. That is default. We also have an Angelot there working on more things. And that is a feature from IntelliJ, which you may know IntelliJ can or by default shows you the parameter names for any codes. Also available for Eclipse. So if you say I have no idea how grid layout works and what does one mean, you can actually enable it and it will tell you this is actually the name of the parameter as num call. And then you get more information about it. My favorite feature in IntelliJ is actually the debug feature which shows you the debug information. While you debug instead of like using the variable view also available via this plugin from Angelot. Then you basically also in Eclipse you see again via code mining the value of the two string method actually of the element which you're debugging here. Very useful because for a lot of cases you see immediately in the text editor what you're actually debugging without looking at any additional things. The question from Tobias was when will this debug features come to standard Eclipse? And let me park this question when I talk about community involvement. So we're also constantly improving with dark theme. Dark theme in my opinion looks already very good on Eclipse. Sorry on Linux. There's not so nice on Windows and okay on Mac. But there have been changes also being reviewed at the moment. For example, scroll bar on the windows is currently not female bill. But Microsoft did something there. So we may also be able to leverage that to female so the scroll bus. So in every release with dark theme gets gets nicer. If you're a sublime user, you may enjoy this mini map which gives you a little overview of your source code and you can navigate it. It's a structural view of your source code and that is also available since last year from Eclipse. For the latest release in December. And one other thing we plan to have in this release is an API for non blocking notification. I basically hate blocking notification in all tools I use. And so this is a dialogue I don't like to see in Eclipse. I push something I get information that something pushed and I need to actively close it. We hopefully will bring in this release an API where you can have like a little notification window in line not blocking. And once we have this, we can remove more of these blocking dialogues which typically only annoying and not so helpful. Then of course there is also there are other languages out there than Java. I think the Java support is very good in Eclipse, maybe similar in all IDs. But of course there are new languages invented every week. And this new language needs also support for their popular tooling. And fortunately Microsoft has invented this language server protocol where we will have several talks today about. And the language server protocol enables us or any tooling to support very fast editor support for programming language. So Jonas will give also later a talk about this, how difficult it is. Just I don't want to steal this thunder but it's very fast for Eclipse at least to build support for new language if there's an existing language server available. So language server is a locally running component written in whatever language the team choose to select. There's a standardized protocol which you can then use to communicate and adding support for Eclipse is really easy. Red Hat will most likely give you the best JavaScript support available in the world in Eclipse. Because they planning to migrate the Visual Studio Code language server for JavaScript. And not migrated but also reuse it in Eclipse. So the JavaScript tooling at the moment in Eclipse which is not good is based on the custom implementation in Java. But soon the default downloads will switch to a language server based implementation. And then we will use the Visual Studio Code language server. And then you have all these if you're using Visual Studio Code for JavaScript and they have a similar support in Eclipse. Also we are working on Dart support if you're interested in Dart. Fancy new language, not really new but at the moment pushed by Google. We're working a little bit together with the main architect layer for the language server. Looking forward to this and Jonas again will demonstrate that. Now Tobias asked the question when will this debug feature come into Eclipse. And the answer to this question is it really depends because as we heard maybe yesterday from Mark Reinhold in his talk. If you do a lot of things you also typically have a lot of saying in an open source project. And that is definitely true for Eclipse and we heard yesterday from Mark Reinhold is also true for Open JDK. So it depends a little bit Tobias if someone shows up and does the work to polish this debug information then it will be integrated. The person responsible for the debug component is very interested in this feature. So it just takes someone to find the time to polish it a little bit and bring it up and then integrate it. Technology wise everything is there and also the implementation is there. It just needs to be migrated and so on. I actually like this because I think it's a very positive thing because whenever you are decided or determined to do something, something is really annoying you can start working on it and helping us to improve Eclipse. As it's not a company driven open source project it also feels better to me at least to invest my free time into this tooling. Which brings up the question how can you actually contribute to Eclipse? Who did contribute to Eclipse? Maybe a sign of hands? Let's say a small group and if someone tried to do this a few years ago maybe this person got frustrated. It is much easier now these days. For example to build the Eclipse SDK you only have to issue these commands into the command plan. And then a few hours later you will have the Eclipse SDK. That is completely changed to the process five, six, eight years ago where it basically was impossible to build Eclipse if you were not working for IBM and had access to the internal IBM servers. So if you just want to clone the code maybe try something out you can actually build it. You don't have to, you can also just provide a patch. We do regular hackathons in Hamburg and the typical setup for being ready to give a contribution is from our experience five to ten minutes. So you basically need to have a user, you need to sign an Eclipse license agreement that you are actually allowed to contribute code to the Eclipse project. And then you clone your repository then this of course takes time depending on your network and with and then you're ready to contribute. You import the projects and you can basically code. You don't have to figure all these nasty data out how to run the tests. You can take your patch push it to our review system and it will be taken by our review system create using Garrett for that. And it will take your patch and start a build process. So it will basically build for whole repository run or all the unit tests we have automatically and then report if it's the patches technically okay. And then if that is if that happened. So if your patch is technically okay typically a person depending on the area you're trying to contribute will look at the patch and give you feedback or directly integrated. So especially if you're doing just a Java doc typo Garrett patch that goes in extremely fast. Of course if you're doing very complex things and someone needs to actually take time to look at it. But it's it's a really nice process and it has also accelerated significantly the development speed of Eclipse. We basically if I do something and I basically look only at the local scope and then I committed push it to Garrett and 20 minutes later or 40 minutes later depending on the repository. I get the feedback if I broke any tests and then I can just look at the broken tests and while I'm working on something else so it's really nice. If you who's familiar with Garrett sign off hands and it's a little bit similar to GitHub pull requests. But I think it's optimized also for the review process pull requests are nice for contributing but not so nice for reviewing. And Garrett I think is a good trade off for both sides it's really good for reviewing but also good for contributing and helped us to speed up the project quite significantly. So in summary I think the Eclipse community is very successfully and has been successfully in the last years to get broader and implement more ideas. To me personally it's very important that my tools are fast so I'm very happy to see Eclipse getting faster and faster and also the UX is getting way better than when it used to be. I'm not sure if you remember where the restart button was in Eclipse a few years ago it was I think below the print button and convert top delimiters. So if you looked at the file menu and I was exit here and restart was here and above there was print and top delimiter and it was just ridiculous nobody would expect such a thing. So we're working on these silly things but also notification mini map and so on so we're hoping to give you a better user experience. And by that I think I have a few or two minutes for questions. Any questions. So basically the question was why didn't Eclipse in the past package its stuff in a reasonable way. I think this has been solved a few years ago. You find on the download side of Eclipse you find what you call EPPs Eclipse package it's Eclipse packaging project and then you find a download targeted for Java developers and that includes maven gradle tooling a git tooling. So it's a basically what we think Java developer needs included you still can add other things. But there's also that download for Java developers and so on. So just use one of these bundles downloads I personally prefer different way I start with the smallest eclipse I can have and then I add the features.