Angular shitstorm: What's your opinion on the controversial plans for Angular 2.0?

On the Road to Eclipse 4.0

jt
On-The-Road-To-Eclipse-4-0

As a member of the Eclipse PMC and Eclipse platform project-lead, Mike Wilson has been involved in the Eclipse e4-Incubator Project since the beginning. Within e4, the technologies are currently being developed that will form part of the Eclipse 4.0 SDK, due for release in June 2010. In an interview with JAXenter, Mike talks about the background and the aims of the project and answers the critical claim that e4 could be a threat to the coherence of the Eclipse platform.

JAXenter: The first generation of the Eclipse platform (releases 1.0 to 2.1) was primarily an integration platform for software developers. The second generation (Eclipse 3.x) introduced the OSGi Runtime and opened Eclipse to become a general purpose Runtime-Application-Framework. How would you characterize the step from 3.x to Eclipse 4.0?

Mike Wilson: The main design point for Eclipse 4.0 is around making it possible for people to develop Eclipse — both new plug-ins and the base SDK code itself — more easily, more quickly, and without needing to understand every aspect of the internals. Of course, as a side-effect of this, it also becomes easier to move the code in new directions. As new communities come forward, they can engage quickly. Similarly, as new technologies become prominent, it becomes much easier to address them.


JAXenter
: In your blog ‘Eclipse has a future’ you say that the technology-landscape and the Eclipse community have both changed since Eclipse 3.0. How did they change and why isn’t the Eclipse 3.x development line sufficient any more?

Mike Wilson: Obviously, Eclipse 3.x *is* sufficient for the many great uses it’s being put to today, and now is probably a good time to reiterate that we intend to support 3.x and continue development on it for as long as our consumers are using it. The world isn’t static though, and as new opportunities emerge, we need to be able to harness them.

In terms of the technology-landscape, the main pushes I see are:


• much greater acceptance of rich internet applications (RIAs) in domains that were traditionally ruled by “sovereign” (i.e. stand-alone desktop) applications.
• cloud computing (once the hype gets separated from the function).
• multi-language development.
• embedded devices with enough horsepower to need modularity, service architectures, provisioning, etc.
• multi-core systems.


All of these things (and I’m sure more that I haven’t thought of) are important trends that Eclipse ought to be able address. The point is though, if we want to be relevant in another 5 or 10 years, we need to be agile enough to be able to address any new technology that comes along.

The changing Eclipse community is a similar thought, with parts of the community looking to address new problem areas as well as new technologies, while other parts of the community are looking for an ultra-stable base for their products. I believe there’s a wider spectrum now than there was in the 3.0 days.


JAXenter: How will Eclipse 4.0 be able to overcome the limitations of Eclipse 3.x?

Mike Wilson: I can think of quite a number of ways:


• The modelled UI + contexts removes the fundamental constraints on the shape of the workbench — things like a single editor area, views and editors in separate stacks, perspectives in a layer above views/editors, etc. all become matters of *policy* rather than implementation.
• The Eclipse Application Services (the 20 Things) make it possible to implement Eclipse plug-ins in languages other than Java (with JavaScript being the first one).
• Then, once you start building components in JS & HTML, you can look at the possibilities of running your Eclipse as a remote server.
• The flexibility of CSS based skinning of the workbench makes it possible to more easily, and with a wider range of possibilities, control the look and feel of the workbench.
• The Flexible Resources work solves some of the fundamental limitations that made it hard to use the Resource layer in large scale systems, and provides more control over the shape of Projects.

JAXenter: Let’s talk about the e4 development process. Who initiated the e4 project? Are there fulltime committers working on it? Is IBM the driving force?

Mike Wilson: I guess the Eclipse Project PMC recognized the need to do something *like* e4, which would separate the forward looking, innovative, will-take-more-than-one-year-to-finish work from the main development stream, several years ago. The current shape of that started to come together a few months before EclipseCon 2008. As to who are committers on the project, there are actually quite a large number — somewhere around 50, I believe — but many of these are more interested parties who are tracking the work, rather than active contributors. I’d say the core group is around 15..20 with representatives from several companies. Some are full-time Eclipse Project committers, with responsibilities for both the 3.x and 4.0 streams, but others have “day jobs” in addition to investing their own personal time in e4.

JAXenter: Some say that e4 is mainly a project to advance Eclipse Runtime (particularly RCP,) whereas Eclipse the IDE is complete and shouldn’t be changed. What do you think about it?

Mike Wilson: Well, I’m somewhat surprised by this, to tell you the truth. Arguing that “Eclipse the IDE is complete” is like saying “nothing more can happen in the IDE domain”. I don’t buy that at all. I see exciting things happening in real-time collaboration and team development (e.g. Jazz, Google Wave,…), multi-core programming (particularly now that even laptops can have 4 or 8 cores), multi-language/multi-target development, distributed build, large scale systems… Man, the future is *bright* for IDEs! :-) But to be able to address these things you have to have an architecture that can support them. *Some* of this could be done in Eclipse 3.x, but probably not while moving fast enough to avoid being passed by newer contenders.

JAXenter: In the e4 project plan we can find the statement that compatibility is not a primary focus of e4. How do you respond to people that are concerned that Eclipse 4.0 could be a danger for the coherence of the Eclipse platform?

Mike Wilson: I think it’s important to distinguish between the e4 incubator project (which is where that statement applies) and the set of capabilities that we intend to deliver as the “4.0” version of the Eclipse SDK.

Architecturally, “e4″ is a light, service-based platform with a highly flexible, dynamically updatable UI model that can support multiple rendering technologies. In other words, the internals aren’t much like Eclipse 3.x. ;-) However, the Eclipse 4.0 SDK (which is being built with technology from e4), is going to run all API clean, 3.x plug-ins without changes, on your desktop. So, from my POV, the compatibility statement we are making is the same as what has always been said about 3.x. And believe me, to get to that level there will need to be a *strong* focus on building the compatibility layer.

However, I’m well aware that there are plug-ins out there that depend on internal data structures, methods, classes, etc. of the workbench. The odds of those plug-ins continuing to work in 4.0 are low, so I guess the biggest compatibility point is _stop_using_internals_.

I’m not actually worried about this being a “coherence” problem, though. As I said in my blog posting, I believe the adoption of e4 will be organic; people will be using e4 to do new interesting things in particular domains, while still relying on tools built with 3.x for many years. Even switching to building “pure” e4 plug-ins (i.e. ones that do not require the compatibility layer) doesn’t prevent them from interoperating with 3.x ones, as long as the compatibility layer is available.

JAXenter: In the e4 white paper, there are listed seven main working areas: A new Programming Model, Modeled User Interface, Declarative Styling, Web to Desktop, Desktop to Web ( new SWT-Port/ Eclipse Rich Ajax Platform), Declarative Widgets (XWT, TM), Flexible Resource Model. Is this architectural plan fixed or can we expect changes?

Mike Wilson: All of these items are there because they were high enough on someone’s radar that they were willing to invest in implementing them. That’s really the nature of an incubator, which is what e4 is. Of these, the one that seems to have gotten the least traction is the “new SWT-Port.” This was actually very good work, but it has been difficult to find real-world code that could benefit from it. The others all seem to be making good progress.

I could also imagine new areas being added to the list. But for this to happen, at this point, it would need to be very clear that there were significant benefits, an excellent fit with the other work being done, and a strong community that would see the work through to completion. Realistically, I think that even if this was to materialize today, getting it into the *first* release (July 2010), would be difficult.

JAXenter: According to the plan there are several different UI Frameworks under development. Can these UI Frameworks exist simultaneously or will it be necessary to take an architectural decision?

Mike Wilson: There’s been some healthy discussion about this in the e4-dev mailing list, but I don’t think it’s been resolved. My personal feeling is that having multiple frameworks available is a good thing, as long as you don’t need to know all of them to do your job. Being able to use whatever framework suits your problem domain is great. As long as the separation is there, so that your plug-ins and mine can work together without us needing to know how the other one is implemented, who cares what technology you used?

JAXenter: Some days ago, you released e4 1.0 Milestone 1. Where do you stand today and what work has to be done until Eclipse 4.0 in summer 2010?

Mike Wilson: In the time since r0.9 shipped, we’ve been working towards the final versions of the internal structures (e.g. the UI model classes), replacing “hacks” in the backwards compatibility layer with real code, implementing more of the JavaScript support, defining and documenting the Eclipse Application Services, working on the CSS engine and SWT widget support, improving the UI frameworks, and even moving some of the code into 3.x (e.g. the Flexible Resources work). I believe there’s a lot of work to be done on each of those paths, between now and the end of July 2010 — a lot of work that could use your assistance. If you’re interesting in helping out, please, join the e4-dev list and let us know.

JAXenter: The first generation of the Eclipse platform (releases 1.0 to 2.1) was primarily an integration platform for software developers. The second generation (Eclipse 3.x) introduced the OSGi Runtime and opened Eclipse to become a general purpose Runtime-Application-Framework. How would you characterize the step from 3.x to Eclipse 4.0?

Mike Wilson: The main design point for Eclipse 4.0 is around making it possible for people to develop Eclipse — both new plug-ins and the base SDK code itself — more easily, more quickly, and without needing to understand every aspect of the internals. Of course, as a side-effect of this, it also becomes easier to move the code in new directions. As new communities come forward, they can engage quickly. Similarly, as new technologies become prominent, it becomes much easier to address them.

JAXenter: In your blog ‘Eclipse has a future’ you say that the technology-landscape and the Eclipse community have both changed since Eclipse 3.0. How did they change and why isn’t the Eclipse 3.x development line sufficient any more?

Mike Wilson: Obviously, Eclipse 3.x *is* sufficient for the many great uses it’s being put to today, and now is probably a good time to reiterate that we intend to support 3.x and continue development on it for as long as our consumers are using it. The world isn’t static though, and as new opportunities emerge, we need to be able to harness them.

In terms of the technology-landscape, the main pushes I see are:

• much greater acceptance of rich internet applications (RIAs) in domains that were traditionally ruled by “sovereign” (i.e. stand-alone desktop) applications.
• cloud computing (once the hype gets separated from the function).
• multi-language development.
• embedded devices with enough horsepower to need modularity, service architectures, provisioning, etc.
• multi-core systems.

All of these things (and I’m sure more that I haven’t thought of) are important trends that Eclipse ought to be able address. The point is though, if we want to be relevant in another 5 or 10 years, we need to be agile enough to be able to address any new technology that comes along.

The changing Eclipse community is a similar thought, with parts of the community looking to address new problem areas as well as new technologies, while other parts of the community are looking for an ultra-stable base for their products. I believe there’s a wider spectrum now than there was in the 3.0 days.

JAXenter: How will Eclipse 4.0 be able to overcome the limitations of Eclipse 3.x?

Mike Wilson: I can think of quite a number of ways:


• The modelled UI + contexts removes the fundamental constraints on the shape of the workbench — things like a single editor area, views and editors in separate stacks, perspectives in a layer above views/editors, etc. all become matters of *policy* rather than implementation.
• The Eclipse Application Services (the 20 Things) make it possible to implement Eclipse plug-ins in languages other than Java (with JavaScript being the first one).
• Then, once you start building components in JS & HTML, you can look at the possibilities of running your Eclipse as a remote server.
• The flexibility of CSS based skinning of the workbench makes it possible to more easily, and with a wider range of possibilities, control the look and feel of the workbench.
• The Flexible Resources work solves some of the fundamental limitations that made it hard to use the Resource layer in large scale systems, and provides more control over the shape of Projects.

JAXenter: Let’s talk about the e4 development process. Who initiated the e4 project? Are there fulltime committers working on it? Is IBM the driving force?

Mike Wilson: I guess the Eclipse Project PMC recognized the need to do something *like* e4, which would separate the forward looking, innovative, will-take-more-than-one-year-to-finish work from the main development stream, several years ago. The current shape of that started to come together a few months before EclipseCon 2008. As to who are committers on the project, there are actually quite a large number — somewhere around 50, I believe — but many of these are more interested parties who are tracking the work, rather than active contributors. I’d say the core group is around 15..20 with representatives from several companies. Some are full-time Eclipse Project committers, with responsibilities for both the 3.x and 4.0 streams, but others have “day jobs” in addition to investing their own personal time in e4.

JAXenter: Some say that e4 is mainly a project to advance Eclipse Runtime (particularly RCP,) whereas Eclipse the IDE is complete and shouldn’t be changed. What do you think about it?

Mike Wilson: Well, I’m somewhat surprised by this, to tell you the truth. Arguing that “Eclipse the IDE is complete” is like saying “nothing more can happen in the IDE domain”. I don’t buy that at all. I see exciting things happening in real-time collaboration and team development (e.g. Jazz, Google Wave,…), multi-core programming (particularly now that even laptops can have 4 or 8 cores), multi-language/multi-target development, distributed build, large scale systems… Man, the future is *bright* for IDEs! :-) But to be able to address these things you have to have an architecture that can support them. *Some* of this could be done in Eclipse 3.x, but probably not while moving fast enough to avoid being passed by newer contenders.

JAXenter: In the e4 project plan we can find the statement that compatibility is not a primary focus of e4. How do you respond to people that are concerned that Eclipse 4.0 could be a danger for the coherence of the Eclipse platform?

Mike Wilson: I think it’s important to distinguish between the e4 incubator project (which is where that statement applies) and the set of capabilities that we intend to deliver as the “4.0” version of the Eclipse SDK.

Architecturally, “e4″ is a light, service-based platform with a highly flexible, dynamically updatable UI model that can support multiple rendering technologies. In other words, the internals aren’t much like Eclipse 3.x. ;-) However, the Eclipse 4.0 SDK (which is being built with technology from e4), is going to run all API clean, 3.x plug-ins without changes, on your desktop. So, from my POV, the compatibility statement we are making is the same as what has always been said about 3.x. And believe me, to get to that level there will need to be a *strong* focus on building the compatibility layer.

However, I’m well aware that there are plug-ins out there that depend on internal data structures, methods, classes, etc. of the workbench. The odds of those plug-ins continuing to work in 4.0 are low, so I guess the biggest compatibility point is _stop_using_internals_.

I’m not actually worried about this being a “coherence” problem, though. As I said in my blog posting, I believe the adoption of e4 will be organic; people will be using e4 to do new interesting things in particular domains, while still relying on tools built with 3.x for many years. Even switching to building “pure” e4 plug-ins (i.e. ones that do not require the compatibility layer) doesn’t prevent them from interoperating with 3.x ones, as long as the compatibility layer is available.

JAXenter: In the e4 white paper, there are listed seven main working areas: A new Programming Model, Modeled User Interface, Declarative Styling, Web to Desktop, Desktop to Web ( new SWT-Port/ Eclipse Rich Ajax Platform), Declarative Widgets (XWT, TM), Flexible Resource Model. Is this architectural plan fixed or can we expect changes?

Mike Wilson: All of these items are there because they were high enough on someone’s radar that they were willing to invest in implementing them. That’s really the nature of an incubator, which is what e4 is. Of these, the one that seems to have gotten the least traction is the “new SWT-Port.” This was actually very good work, but it has been difficult to find real-world code that could benefit from it. The others all seem to be making good progress.

I could also imagine new areas being added to the list. But for this to happen, at this point, it would need to be very clear that there were significant benefits, an excellent fit with the other work being done, and a strong community that would see the work through to completion. Realistically, I think that even if this was to materialize today, getting it into the *first* release (July 2010), would be difficult.

JAXenter: According to the plan there are several different UI Frameworks under development. Can these UI Frameworks exist simultaneously or will it be necessary to take an architectural decision?

Mike Wilson: There’s been some healthy discussion about this in the e4-dev mailing list, but I don’t think it’s been resolved. My personal feeling is that having multiple frameworks available is a good thing, as long as you don’t need to know all of them to do your job. Being able to use whatever framework suits your problem domain is great. As long as the separation is there, so that your plug-ins and mine can work together without us needing to know how the other one is implemented, who cares what technology you used?


JAXenter: Some days ago, you released e4 1.0 Milestone 1. Where do you stand today and what work has to be done until Eclipse 4.0 in summer 2010?

Mike Wilson: In the time since r0.9 shipped, we’ve been working towards the final versions of the internal structures (e.g. the UI model classes), replacing “hacks” in the backwards compatibility layer with real code, implementing more of the JavaScript support, defining and documenting the Eclipse Application Services, working on the CSS engine and SWT widget support, improving the UI frameworks, and even moving some of the code into 3.x (e.g. the Flexible Resources work). I believe there’s a lot of work to be done on each of those paths, between now and the end of July 2010 — a lot of work that could use your assistance. If you’re interesting in helping out, please, join the e4-dev list and let us know.

Author
Comments
comments powered by Disqus