E4/Languages

Historical Document: Work never progressed beyond original E4/JavaScript development

Support for Multiple Languages

Although there are many reasons why it is desirable to support Eclipse development using multiple languages, in general these can be broken down into two broad categories:

1. benefits of using a particular language
2. benefits from enabling dynamic development

The benefits of being able to develop for Eclipse using specific languages include:

We extend the ability to develop for Eclipse to those who know how to program using that language.

This has potential to both increase the size of our community, and to make the experience better for our existing developers. For this to work however, it requires the resulting experience to be first-class. It isn't enough to be able to build toy applications; all the power of Eclipse must be available, and the programming style needs to be appropriate for the language. A good test case would be that some of the 4.x SDK plug-ins should be developed in some other language(s).

We allow Eclipse to be used in contexts where only that language can be used.

Of course, this assumes that the infrastructure to start the plug-in is available in that context, but this does not imply that all of Eclipse needs to be there — think "JavaScript bundles that run on the desktop and in web pages".

Depending on the direction that we take, OSGi could become significantly more flexible

Minimally, we need to extend OSGi to support the ability to recognize bundles written in other languages and locate/make available the required resources in order to run them. It's worth at least considering whether OSGi itself could benefit from being implemented in other languages, as way to bring the capabilities it provides to new environments (e.g. OSGi for the web, OSGi for (non-Java) embedded systems, etc.)

By enabling a more dynamic development style within Eclipse we:

make eclipse more malleable

By making the capabilities that Eclipse provides dynamically available, it will be easier to manipulate the appearance and behavior of Eclipse applications. For example, developers will be able to write code that drives other parts of the system (a la AppleScript). In addition, the boundaries between programmatic and declarative APIs will be reduced (e.g. plugin.js versus plugin.xml, or use of JS instead of core expressions).

enable new debugging workflows

For example, it will be possible to open views on the running workbench to introspect on the current state of the model and dynamically manipulate it. This will be possible without starting a second copy of Eclipse and/or running in debug mode, which greatly increases the ability to deal with those transient how-did-I-get-in-this-state problems.

simplify the task of implement macro recording/playback support

Although additional work is required to providing macro recording, the kinds of changes that must be made to support dynamic access to the Eclipse functionality are also required for effective macro support.

It could be argued that it is possible to make Eclipse development be more dynamic without moving to a different language, but the complexity of modifying java classes on the fly and inserting them into a running VM makes this difficult. Alternatively, using an interpreter for Java syntax is also possible, but this also introduces additional complexity, since the map between the running Java and the interpretation of it is complex. In any case, using Java directly makes it too easy to rely on Java code, rather than explicitly making the required functionality available as language neutral API.