Jump to: navigation, search

E4/Languages

< E4
Revision as of 09:36, 9 May 2008 by Mike wilson.ca.ibm.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Support for Multiple Languages

[Yes, this is a WIP.]

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 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:

It could be argued that making Eclipse development be more dynamic without moving to a different language, but the complexity of modifying java classes on the fly

- OSGi flexibility - Scripting - Grow the community - Dynamic development - Target dependencies