Thanks for having me here. I am currently the platform UI co-lead and a long-term contributor and developer and our main focus in the platform is to make it stable again, performant and also integrate more contributors. As you know in the past there were some issues with the Eclipse platform especially we got contributions that were not picked up, we have a codebase which is huge and large and we are trying to work on all these edges to make Eclipse more agile and more usable to all users.
Alex: There has been some recent changes within the user experience in Eclipse and in the platform specifically. I wonder if you can tell us a little bit about them.
If you look at the Eclipse platform releases we have the 3.x stream, and we have the 4.x stream. The first 4.x release was 4.2 and it introduced lot of new concepts but also the UI was not polished enough for some people so what we did in 4.4 we made an attempt to make it look nicer, react nicer, have better defaults so that people who just start up Eclipse have a nicer user experience and there were some little issues like line numbers, white space issues, CSS cleanups, so that the whole experience is nicer. In the current release we are building on top of that and introducing functionality that is just nice, just making it faster reacting, making certain things which were a little bit longer to do like click events faster, so that you just have one click to close everything and so on, editors just close if you close the project and not stay open. And we are hoping that the 4.5 release will again attract more users like the 4.4 release.
2. Some people have said that the code assist in Eclipse is slow, has that always been the case?
It’s not necessarily slow but of course if you introduce a new API rule set like we did for 4.x it’s not that well proven like we have API which is ten years old. So, what we already did in every release, we have a focus on performance and one of the nice things that we have now in the current release is a contribution from Google where we can monitor UI freezes, so whenever we see a UI freeze (which is configurable, so however you configure it) so that if the UI freezes four hundred milliseconds, we directly see the stack trace and then we can work on this, making it faster.
3. How do those reports get uploaded back to the Eclipse foundation for the developers to work on?
There is a very nice side project of a different company [Coderrails] which is an error reporting tool, so our UI freeze monitor is integrated with this tooling, and this tooling is an optional component of the Eclipse IDE which connects to the server and uploads it and makes it available for all our developers. But we are also using direct communication for projects, for example we as a project work relatively closely together with the EGit project so whenever I have a stack trace in the EGit tooling I just send it to Matthias Sohn for analysis and they typically fix it within one or two days. And it’s a big game for us and also for our users because we see where actually the users have the most issues, and they can focus on them, not solving an issue which only one person has, but really focusing on things which thousands of users have.
Alex: And a number of all those fixes have already been introduced with Eclipse Mars which is coming out in July 2015.
That is true, if you go for the current milestone you already get these fixes, what we have already have integrated but we are still working on this and all other projects also benefit from this because as the platform everyone builds on top of this, and we are seeing in other projects also that we are looking at error reports for these UI freezes, and improving the whole experience; because I think one of the issues in the past was that projects were a little bit isolated, and we are trying to break this a little bit by getting more in the action for everything and providing these services also for other projects, so that they also can make the whole experience nicer.
There is a way for opting out and there are concerns but they are luckily handled by other people. So we just look at the data, at the technical data and the [Eclipse] Foundation and the developers of this tooling look about the privacy concerns, so I am luckily out of this picture.
Several things. I think if you look at the performance side we have new API — there's a new Job API which basically can group certain activities and restrict them so that they are not overloading your CPU; for example text search, this was a patch from Google, we have integrated that and you see a speed up factor of five or ten for large searches. A lot of JDT functionality is already using this, also contributed by Google, so general JDT functionality should get much faster. But also we have simplified certain APIs like little things which were annoying for developers; for example, you had a call to get a selection but it always returned a certain type and you always had to cast to a certain type so we introduced just a method to get this thing to make it general the API simpler to use or to implement. We also introduced in lots of important places generics, so that again you avoid casting and can clean up the code and get more type safe, so in general lots of clean ups but with the focus of making the code easier to maintain and faster to perform.
6. What about Java 8 is the platform moving towards Java 8 or is that something for the future?
It is not moving in Mars, we were finally able in this upcoming release to move to Java 7. It was a bit of a fight but now it has been accepted, and the platform UI team plans in the next release to go to Java 8 and we will see how much resistance we get for this decision, so if there is not too much resistance, or not good reasons not to do it, we plan to upgrade it, just also again to simplify our code base and benefit from all these nice features from Java 8.
Alex: So the July 2015 release will rely on Java 7 and then hopefully the July 2016 release will be based on Java 8.
That’s what we hope and what we are targeting for.
Alex: So you have also been involved with something called saneeclipse. I wonder if you can tell the listeners a little bit more about what that is.
saneeclipse is a little project from our company [Vogella], which I co-founded and is a kind of a test ground, so what we see a lot with our customers and our developers which we support is that they use Eclipse as it is, so they download it and they just use it and they get frustrated. You talk to other users of other IDEs and they tell you that code completion is so much faster, that certain things work just better, and they are also available in Eclipse but they are not enabled by default in certain cases. And saneeclipse is basically a set of plugins, which enables these things which we think are useful, a “sane” configured Eclipse, for these developers. So they just have to download this certain plug-in, and then Eclipse just behaves the way we think it’s optimal configured. And we use this as a test ground, for example code completion was delayed in the Java development tool so whenever you triggered code completion it waited two hundred milliseconds — which doesn’t sound a lot but for some developers if they are fast typers this felt like it takes a long time to come up. So we integrated this in saneeclipse, had a test ground for it, had several hundred users using it and then collaborated with JDT to make this change, they also tested it and they said ok, we also see the benefit of it, and just changed it. And it helps us to communicate with other projects about these changes.
Alex: So now when you use Eclipse Mars the code completion is going to be much faster, when it comes up by default.
It is the same speed but it will feel much faster by default. So people will hopefully maybe not recognize it but just say oh it’s really fast for Eclipse IDE.
Alex's full question: Feeling fast and feeling better is often subjective isn’t it? When you use something you tend to notice the benefits of that if delays have been reduced. You are talking about Google having contributed the error reporting detection or the UI freeze detection, and a few other things as well, how are you growing the platform committer and contribution base and how are you using tools at Eclipse to make that easier?
There is also one of our main targets for this release to get more people involved, and now a new person from Google has joined the platform team as a committer, after working a little bit on the platform. We are a little bit conservative with bringing in immediately new people because the platform has to be very stable and people need to understand the rules, but in the past it was almost impossible to join this team, so now we are encouraging these people a little bit more, and we are doing this by reviewing very actively their code contributions. What we see is that if we get immediate feedback to any code reviews like using the Gerrit review system then people get motivated and want to do more, and more and more and more, and they also get better at what they are doing. This way we already have three people, nominated committers and there are few more upcoming, and it’s really fun to see these people also very motivated, also with different skillsets than the existing developers, because they learn Gerrit from the start, and they also are feeling natural to do code reviews, and so I hope to create a positive spin there, that these people getting Gerrit to know joining Gerrit first from the contributor side and then from the committer side, help us to increase the process of getting fixes in. And it is already working, the Google person is very active also in reviewing the other people which on boarding at the moment are also helping and it really helps to get the whole thing running again and make it faster and attractive for other people.
It is definitely not as simple as GitHub pull requests, work on a branch is of course easier than Gerrit which is based on a concept of commit, so you basically do a review and update the commit, but from our perspective is a perfect system because it makes our flow simpler. The build system validates every Gerrit review system, it builds it, it does the tests, which builds up confidence for the contributor as well as for the committer. We can give easy feedback, people see it immediately, we can do comments line by line, and that again helps both sides. I talk a lot about Gerrit and I always say it’s a perfect system for both the committer and the contributor because it is easy for both sides after initial setup. Also the set of tools is growing here, the Eclipse Git tooling recently introduced the ability that if you clone from a Gerrit server, it automatically configures Gerrit. So the setup is now as simple as cloning it from Eclipse, and then you have everything configured already, you just need to sign certain agreements that the code is actually written by you and so on and then you can start contributing. I think the whole process, the speed which Gerrit gives us makes it much more fun for people, we know if we do something, we are into it, we think about it; but if it takes two months to get some feedback on it, you are already somewhere else, and thinking about something else, but if you get the feedback in a few days which Gerrit enables us it helps both sides.
We do have a list of bugs which we have classified and this is also available on the corresponding Wiki page, it is dynamically generated so whoever is interested in this, and there is a little prize involved like an Android tablet can look at this page and pick a bug, and start working on it.
Alex: Lars Vogel, thank you very much.
Thank you very much for having me.