I actually remember a symposium we had in Ottawa maybe four or five years ago now, it was an IBM site but attended by a broad range of companies, it was over 30 people there, and it was to look at a couple of things to do with the platform. So, one thing was complexity, it was hard for us to fix even certain kinds of simple bugs because of the complexity of the platform. It had a design and an architecture behind it but it had been evolving for six or eight years at that point, organically, as needed. And it was also well attended by people who provide RCP apps. They were interested in simplification, it was really hard for them to get up and running, but there was a lot of framework you had to put in place and in most cases, the first cut of the RCP app then looked like a scaled down IDE and that wasn’t what they were looking for. So, I remember those were two primary reasons that had come from our community and us ourselves. There were some other people concerned about different areas like preferences and resources. Those ones didn’t really take off, but what came out of our discussions at that was a simplification to the RCP, what if it was modeled, what if it was modeled and the model was the primary, obviously it’s the standard MVC, renderers then took care of the next step, changes fed into the model and got rendered. So, that was the beginning and that was how we started down this path.
Alex: With the models and the renderings presumably that gives the possibility in the future of different rendering models for the application to come about as well.
That, the initial cut of that was people were hoping that would work out because of styling, styling in the platform still always looks like an IDE that was styled slightly differently and obviously here, you’ve probably seen Tom Schindl talk about his Eclipse FX and his work in Java FX, he has been able to take advantage of the Eclipse 4 model to provide a completely different technology renderers rather than SWT renderers. But even the initial plan was hoping that as people either enhanced the model or wanted to provide slightly different looks they would be able to replace renderers.
Yes, that was the hope. I am not sure what their plans are, because I know as part of RAP they did have to provide an effective replacement workbench to help them manage the things they need to do. But, it would certainly had been nice if with a little work they would be able to swap out some renderers and get some of their stuff for free when targeting the web. Q4 So, Eclipse Juno 4.2, the recent release of Eclipse, has been moved over to the 4.2 platform and support on the 3.x lines has come to an end. How difficult and how long a time scale has this taken to achieve?
In the background we have worked on the Eclipse 4 technologies for a while, so that you could create an Eclipse 4 app and then we had spent two years updating the workbench in terms of Eclipse 4, so in effect providing that compatibility layer before we’ve attempted it on Juno with 4.2. So, it was 4.0 which was called some kind of beta, 4.1 might have been called developer preview release and then 4.2 was the next step. I’ll point out that we have walked away from, not walked away from, the Eclipse 3.8, it’s still provided, it’s still solid, it’s continued to be supported as well as any of the other previous maintenance releases, I know we did release stuff into 3.8.2, and so just like 3.7.2, it will continually get less and less attention now.
4. When 4.3 comes out there is no intention of providing a 3.9, for example?
Correct. When we made the transition into Juno, in the release train, the cross projects list and the other projects really stepped up and helped us out, some of them did have to make some changes, the API that they were using slightly differently or incorrectly, but a lot of their feedback was “here is what we do” and we had to then help them by fixing problems in the platform, obviously.
For people that are feeding into, I guess it depends on where you are going to start, I know some functionalities are plug-ins into the IDE and they might have to support Helios, Indigo and Juno. In that case, you are pretty well going to be restricted to the Eclipse 3.x APIs, even in Juno provided you stick to API patterns that should continue to work. And in Kepler as well, nothing is happening there. If you are writing a full-on plug-in but you are starting in Juno, you’ve got no requirement to support the backwards releases, you would still probably start off with a lot of the Eclipse 3.x APIs, but Eclipse, I mean the workbench, the compatibility layer is implemented in terms of Eclipse 4 and that would give you some opportunities to start grabbing on to Eclipse 4 technology that is exposed and using it, because as long as you are going forward, you will never have a problem, that will always be there, the forward goal is to expose it more and more and make more and more of that available.
But I would still probably start with the 3.x API, to plug into the IDE, to provide developer plug-ins, you are probably going to need the workbench services, the workbench has about 20 different things that people are used to, the windows, the selection service, the progress service, progress views, preferences, all that kind of things. There’s a long term goal to help splitting those out, making them available to Eclipse 4 apps, to be easily consumable, so you don’t have to have your RCP app look like the IDE and have a 6 MB workbench plug-in smack in the middle of it. You’d be able to write your Eclipse 4 app and style it how you want and maybe just pull in the progress view, say. That’s what you are going for.
Alex: By modulizing the existing services that get provided by workbench.
Right. But I know our focus for the rest of Kepler will be on stability and performance and some minor work to support things like two editors contained within an editor, but the real work to start splitting up the workbench, which is one way, and surfacing a lot more of the Eclipse 4 capabilities will start happening in Luna.
Alex: So, we’ve been talking about Kepler, that’s being released in Summer 2013 and Luna is scheduled for Summer 2014.
Correct.
There are some, one of the hearts of the Eclipse 4 technologies is the notion of runtime IEclipseContext, but it’s the distillation of accessing your services through your own context. Now, in 3.x there has always been or has been for a while a service API, and a number of the standard services that we offer at the workbench are offered through there. And if you were using that already, now everything that’s in Eclipse 4 is also available through that API, so that gives you the opportunity to ask for some Eclipse 4 things and this goes back to the guys who are working in Juno and don’t have a backwards compatibility one, they can ask for some of these Eclipse 4 services even now and then start taking advantage of them.
So, you can in a regular Juno plug-in ask for the MApplication, which is the root of the model and the EModelService and the EPart service and start manipulating it. It’s risky now, depending on what you want to do, because we haven’t fully, part of it exposing Eclipse 4 into the 3.x APIs and the workbench and making it more open, we’ll be making sure that our workbench doesn’t trample all over the model, so if you want to manipulate the model it won’t help if the workbench comes along and says “I need to add a part so I am going to go bang- bang- bang” and the third step tramples over your model. That’s the caution, you’d be able to do some experimentation, but I think caution would be in order.
Alex: So, one of the things Lars (Vogel) was talking about in the past is having, and I think Tom (Schindl) has put together a plug-in for this, is the ability to write your view as a POJO which could then be conceivable directly from Eclipse 4 but then be hosted in a view part kind of binding layer so that the same code could also be used in a 3.x application.
I know Tom has written what’s called the 3.x bridge, which is still in the E4 incubator and the tools, its goal though is to provide some of that capability, the runtime access and the POJOs in 3.x completely, so running on Indigo or running on 3.8, you could use some of that, you could host your stuff in 3.8, your POJOs, and then in Juno actually or in Juno RCP use them as Eclipse 4 proper views, say, and that bridge would allow you to hop between the two. In Juno itself there is a part of the bridging capability that’s missing. Juno uses Eclipse 4 parts, POJOs, to then host the workbench, your standard workbench part. It works because we own the Eclipse 4 part, to then pull in Eclipse 4 stuff, you are providing the Eclipse 4 part and the part that is missing is how do we float a workbench part and edit a reference. The things that the workbench expects, that participates fully in the lifecycle, because you can add your own MPart into the model and it will be instantiated, but it won’t show up in show view, for example, because it doesn’t have the right attributes, it doesn’t participate correctly into the selection service because there is no part to offer for it. That part of the bridge won’t be in Kepler, but is definitely coming in Luna.
I know I probably wouldn’t do it, it would be modifications to the workbench and the workflow. In my head I don’t see it as being phenomenally complicated, it’s like four or five pieces of puzzle that have to be in place, so it would probably be able to patch it back to Juno, to an SR2+. But, unless I am told otherwise by the powers of the control Paul, I wouldn’t be patching it back.
8. [...] What tools are there for developing and testing Eclipse 4 applications?
Alex's full question: And I guess the real issue is quite a lot of plug-ins, quite a lot of assistance, say, we are going to run on Eclipse -1 or Eclipse -2, by the time Luna comes out Eclipse -2 is going to be Juno and I think that when Luna comes out the providers of common plug-ins EGit and Mylyn and so, are probably going to be quite comfortable saying the lowest version we are supporting is 4.2, we are probably a couple of years away from that point. So, what tools are there for developing and testing Eclipse 4 applications?
I know I have seen, there is still an E4 incubator project and it’s kind of a platform level incubator and it’s a grab bag of lots of different technologies that are being tried out and will be consumed by the platform, but right now the E4 tools is in the incubator project. They provide a nice model editor for editing your application and when installed in the SDK it also provides a live model editor so you can edit your workbench model live. Now, with the caveat that of course depending on what you do we don’t like it things can get a little hairy. There is also a tool called CSS Spy in there, which for picking any particular widget, will then give you the CSS information and a little bit about the hierarchy that can be seen at the point.
So, much like PDE Spy, I guess its original intent was “something is styled wrong, why is it styled like that?” or “oh, this is styled right, what’s the styling look like?” I believe it also actually allows you to edit the CSS properties live which can allow you to fiddle with things, try out before you pick an existing one. I think that one is really useful for people considering styling the workbench or the more targeted audiences, the RCP guys, they really wanted a lot more control over styling. There is also a lightweight CSS editor, we use it in our appearance page and it’s an Xtext based editor and it’s mostly functional, it’s a useful tool for modifying the CSS that your Eclipse is running in. It was more done because it was a proof of concept “can you run a proper editor in the preferences pages”, because in Indigo you can’t do that at all, it just won’t work. Those are the main three that I am aware of right now and I know there is some discussion, an issue that often comes up when working in Eclipse 4 is “I have all these @Injects, how do I get some kind of content assist or how can I track down information that I can then use”, and right now the answer is some wikis and maybe some code searches. I know there is interest in various quarters about how you could help with content assist or even if not, in our traditional content assist the abilities they say “ok, I’m here, I’m doing this, I have it suggest, well I know that this information is available to be picked up for injection”. But I haven’t seen anything concrete from the guys that are interested in that.
Alex: I guess if you were doing content assist on injection you could almost look at the running Eclipse you mentioned, find out what services that’s providing, pop up list of those.
I know we do have, I guess one tool that is probably not widely known, we have our IEclipseContext, which is our hierarchical runtime information that mirrors the model, there is a context debug view and that gives you insight into the running hierarchy of the IEclipseContext, it also allows you to track down information. In a developer tool you would want more integration with what you are actually doing but that information is available today and a running Eclipse is a good place to start.
One of the reasons they are in E4 is the intent is to fold them into the SDK so that they would be in the SDK. Now, I don’t believe it will happen with Kepler, I am sure that none of the concrete discussions that would have had to happen to have it happen in Kepler have been had yet. We always make sure when we release them, it’s an incubator project so it’s not technically a release, but we do up-version it occasionally, to capture check points, we make sure they are available in the market place and there was just a 0.13 check point, because that is compatible with Juno and then there are model changes in Kepler they are now working on 0.14. So, for Kepler the market place is going to be the place to go and check out these tools, after that I believe the E4 tool guys are happy with the state of their tools, they want to make some more progress on them, but they are getting close to where they feel they would really contribute to the SDK instead of keeping them in a separate incubator.
It’s interesting. Our IEclipseContext are kind of a runtime lookup hierarchy and when I deal with workbench services, they are services in the more generic terms, the framework is offering you to do something for you, so they are not like traditional OSGi services, but I know that we provide a simplified OSGi lookup through the IEclipseContext, so if OSGi services are available you can get them through our context as well. Now, it’s not as rich an interface as actually asking for ServiceRef, you get to add a map with parameters and filters when you do the app, we offer the “ask for the OSGi service just by its most basic interface and we will return the first one that shows up”. In Eclipse 4 one of the other decisions that was made is we use an IEventBroker service, so post it events that we use for model changes, use it for lifecycle events, use it for a whole bunch of things and we tied it into our DI story so that if you are just a consumer of these kinds of model events, you can do a @Inject, a specialized annotation to say you want the event topics, and we will continually update you based on the filter that was passed in at annotation time. Now, that is based on, the implementation of that, our transport if you will, is the OSGi EventAdmin service.
Yes, that would be possible and obviously, we are close to Equinox, they have an EventAdmin service implementation, it was easy to get a hold of, the pattern is well understood, but there is nothing to stop from plugging in another OSGi EventAdmin implementation or even if we have to switch to different transport bus completely that could be done.
I know for a fact we still have some performance hiccoughs, there is a timer that’s running that we want to get rid of. Decisions that were made in the Eclipse 4 architecture should help improve performance, we don’t do a lot of evaluations that the 3.x engine used to do, it used to do a lot of things on change and we do a lot of evaluations only on user request and as long as the user requests don’t take off significantly that should reduce those number of evaluations. Optimizations in the rendering can also increase some or provide some performance improvements, as far as I know in-depth performance improvements haven’t been really one of our focuses right now and we are close to what you can get in 3.8, I believe we are still a little slower, except on startup where we are a lot slower, sorry, on startup we are comparable to a cold startup, it’s about 25 seconds and they are within two or three seconds for a bunch of plug-ins, in 3.x a warm startup then reduces down to 13 seconds or 14 seconds and our startup continues to hover around the 20 seconds mark, so optimization is there, we are actually definitely looking at an improved startup time.
It will be a mixture. I don’t believe the startup time performance improvements will be in Kepler because our startup time event ordering is very fragile, basically every change we have ever made in there has broken somebody or everybody and in Kepler I would be a little hesitant to try something like that unless it was so sinful as to be blindingly obvious. There will definitely be other performance improvements in Kepler and startup time will be a focus in Luna.
I do believe that the 3.x APIs and the workbench APIs will be around for quite a bit longer. So, in the JDT case, where I can’t actually speak for their real plans, I know that obviously their focus with the rapid changes to the language in Java7 and Java8, their focus is going to be on that and as we have already committed to maintain the 3.x APIs they use, they won’t feel any pressure from us while their focus needs to be on that right now. I’d like to see the good Java8 support. Probably not in Luna, as we get to the end of Luna we will definitely be providing migration strategies that we want to make available to plug-ins, starting with a few simple things you can do, to take advantage of some of Eclipse 4 functionality and here’smore long terms we will offer that and we will see what kind of uptake there is.
A21 I think so. I find the community that has already clustered around Eclipse 4, they tend to be traditional RCP developers and plug-in developers who like to take advantage of the new technologies, Lars (Vogel) and Wim (Jongman) and Tom (Schindl), they were already working on plug-ins and RCP apps, they do have ideas about how to migrate forward and I find their community very active, I expect we will continue to hear from them going forward and I think they would have a lot of suggestions. Some of them havd done, like Brian de Alwis, have done migrations of existing RCP apps and actually every year at EclipseCon we see at least one or a couple of proposals from people who have migrated their 3.x apps to Eclipse 4. I find them full of useful suggestions, hiccoughs they’ve hit, things to watch out for and good advice.
So, in the platform I haven’t seen a large uptake just because of the Git migration. Now, the platform is a big complex interwoven thing that compiles to about 6 MB, so I understand that just switching your SCM isn’t going to highlight anything. I know that recently we’ve turned on Gerrit on a couple of platform repos, including platform UI, and as a committer I am finding Gerrit much more useful, it’s useful for people who push things there, it’s a quick review cycle, Gerrit allows you to keep their patch sets up to date using all the Git functionality, but with a nicer interface, and the reviews are easier, they are easier to consume, we obviously allow contributions from GitHub, but yanking stuff from GitHub to use is a pain in the ass, because there is no tooling support for it. Gerrit, and then EGit has its Gerrit support, allows us to pull those things in and since we’ve committed to using Gerrit I have actually seen a slight uptake of contributions coming in. We make it a priority to deal with contributions that come in and that will encourage more contributions, I feel.
I know from my point of view that we have good infrastructure in place with Eclipse 4 and the two biggest things that I would like to see is: one, the decoupling of workbench services which is a simplification for the RCP guys where you can just pick up three services and you don’t need the entire kit and caboodle. And the decoupling exercise will also simplify those services and then maybe they can start accepting some enhancements. Certain services are very tightly coupled and you pull on a thread and the whole thing comes apart, that makes enhancements very hard to do. The second thing which is bigger I think for other members of the community is to start exposing some of the Eclipse 4 technologies and patterns into just people writing plug-ins for the IDE, so anything that we can do and simplifies their life and makes these things available and they work smoothly with the 3.x APIs, I think that will be a big win because that will be the path for people who want to come in at the end of Luna or whatever after and they want to write some Eclipse plug-ins for the IDE and we will be able to offer them “here is the Eclipse 4 steps that you could do, and then yes you still have to go to these 3.x APIs, but we won’t trample over these Eclipse 4 things that we offer you”. Those are the two biggest things I see, but especially the decoupling of services, that’s a big thing, I think that will continue on past Luna. Hopefully, the community has already prioritize some of the services they would like to see and so we are going to start on those, like the ProgressService, that one has cropped up again and again, they would like to use that in Eclipse 4 and then we’ll move on from there.
Alex: Paul Webster, thank you very much.