equinox
alternate runtimes

 

Eclipse currently uses a home-grown runtime model. That is, the runtime model/mechanism was designed and implemented specifically for Eclipse. This is good in that it has been highly optimized and tailor. This is less than optimal in that there are many issues which are complicated and having a unique runtime mechanism does not allow us to reuse the work done in other areas (e.g., OSGi, Avalon, JMX, ...). Further, this approach makes it hard for users in those other environments to use Eclipse as there are model contentions.

One of the goals of Equinox is to look at alternate runtime models and investigate their use as a base runtime for Eclipse. This is a tall order. The good news is that even if we fail to get full integration, we will no doubt learn a great deal and understand techniques for partial integration.

Here is a list of items that needs we'd like to go through for alternate runtimes.

State of the art

There exists a number of technologies in the Java world that support concepts similar to dynamic plugins. The following table lists these technologies from an Equinox perspective.

Issue OSGi Eclipse Avalon JMX Tomcat
How are libraries shared? Imported or exported packages are declared in the manifest. The Framework assures a single namespace for these packages. Sharing can be managed externally through "services". Plug-ins export classes/packages/jars and import all that is exported by another plugin. Plugins do not automatically re-export imported libraries.
Plugin private libraries supported? Yes Yes
Multiple versions of the same library? Only as private libraries Yes. Via private libraries and "library" plugins. Multiple versions of the same "library" can be loaded concurrently. Plugin dependencies are managed by plugin version and matching rules.
How are ClassCastExceptions prevented for shared objects? Single shared namespace Version dependencies and export rules help reduce the chances but exceptions are still possible.
How are new/updated dynamic plugins discovered? Plugins register an object in the service registry. Changes in the registry are send to listeners. On platform restart.
What security model is provided? J2SE security with permissions for registering services based on service interface name, and permission for importing/exporting packages. Extensible for domain resources. Jar signing.
What is the delivery model? A single JAR file with a number of manifest headers. On disk = manifest file + libraries and other files. In update site = single jar containing disk structure.
Tooling support? IBM and ProSyst have tools for bundle development in Eclipse. Eclipse JDT and PDE provide direct support.
Life Cycle primitives? install, start, stop, update, uninstall startup, shutdown events sent to the plugin in question.
Persistent data management? Plugins have their private storage area that is disposed of when they are uninstalled Private storage area.
Any issues with 5000 plugins? An implementation should probably be optimized for this because it is not the "normal" configuration. There are many potential optimizations Initial startup slower as registry is parsed. Second startup fast. Memory an issue in all cases.
(Remote) Management model? The environment is managed through services in the service registry. This is extensively supported. No remote management. Eclipse update/install tools configure a local install and pull updates/new versions.
Boot time issues? Supports lazy resolving and has "start-levels", allowing fine grain control over booting. Lazy plugin activation. Eager discovery of plugin content.
Plugin-to-Plugin collaboration? Yes, through packages and service registry. Yes, through plugin dependencies.
Native code?
(E.g. the SWT dll)
A dynamic plugin can contain native libraries for different platforms. Manifest headers for OS, OS version, and preferred language are used to load the right library in memory. Yes. Plugins can carry any needed native code. Integrated support for OS, Window System, Architecture and National Language differentiation.
Issues? Isolation is not perfect. If plugins are not well programmed they may prevent garbage collection. Isolation is not perfect. Sloppy code references can cause early activation of plugins. Plugins can do too much work on startup.
Equinox Applicability? Seems very suitable to start with Equinox should be an improvement over Eclipse with equivalent or better performance characteristics overall.
Licensing? Freely downloadable from the web site without click through license. Can be freely implemented with the standard disclaimers). Common Public License.
Implementations?
  • 4D Home
  • Acunia
  • Atinav
  • Connected Systems
  • Espial
  • e-Tango (open source?)
  • Gatespace
  • IBM
  • Melco
  • OSCAR (open source)
  • ProSyst
  • Samsung
  • Sun Microsystems
  • VDO
eclipse.org
Links www.osgi.org (main web site) membercvs.osgi.org For members only eclipes.org
How to get started? An existing open source OSGi implementation could be used to start with (OSCAR, eTango) or IBM could be asked if it wants to open source SMF? We then have to see if static-plugins can be adapted to dynamic-bundles.