[news.eclipse.technology.equinox] Re: Eclipse - OSGi Comparison

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Some points of clarification:

- Eclipse plugin code is private by default.  The following extract from the
doc:
"Each <library> element can specify which portion of the library should be
exported. The export rules are specified as a set of export masks. By
default (no export rules specified), the library is considered to be
private. "

It just happens that most people export "*".  That was their explicit choice
however.

- OSGi's encapsulation is not (to my understanding) stronger than that of
Eclipse.  For example, most of the core resources plugin's API is spec'd
with interfaces.  The implementation is almost completely separated.  Again,
this was a design choice the plugin developers made.  It was not forced on
them by the infrastructure.  SWT would be much worse off if they were forced
to write interfaces for everything.  What you can't do natively in Eclipse
is "substitute" implementations using some sort of service mechanism.  The
OSGi service model and Eclipse extension/extension-point model are different
and complementary.

- The fragility of the Eclipse update story is a bit of a red herring.  You
could easily see the Eclipse "plugin container" as being Runtime + Update
Core rather than OSGi bundles.  These two plugins do the bulk of the plugin
management.  In the same way as you would have a textual/minimal
graphics/HTTP UI for OSGi to manage bundles in a faulty install, such an
interface could be implemented on Eclipse to manage faulty plugins/features.
You are not pointing out an inherent flaw but rather a missing usecase.  Is
this sort of facility part of standard OSGi implementations?  Since OSGi
does not spec much about install/update, its unclear how it particularly
helps in this situation.

- totally minor nit:  "self-hosting" already means something in the Eclipse
community (i.e., running an Eclipse target from an Eclipse development
workspace).  Using that same term in this context will be confusing for
people.

- Finally, I must re-emphasize Pascal's comments.  I'm not entirely sure how
to talk about the things that we produce (especially if they are new) but do
believe it is confusing and misleading to call them Equinox. Further, there
are several aspects to the project.

Jeff

"Olivier Gruber" <ogruber@xxxxxxxxxx> wrote in message
news:b3e9b2$frb$1@xxxxxxxxxxxxxxxx

> This posting is a first attemtp at comparing OSGi and Eclipse. I believe
> that OSGi is a very interesting open standard to study for Equinox.
However,
> Eclipse and OSGi have taken different technology stances on some core
> aspects of their platforms. This is certainly not to say that OSGi is not
a
> great candidate to look at.
>
> One of the first advantages is to leverage an existing open standard
rather
> than reinventing the wheel. When Eclipse started, OSGi was also in its
> infancy and therefore an unlikely choice. Since then, Eclipse and OSGi
have
> both evolved toward a surprising similarity, as we will discuss in the
> following paragraphs. We therefore feel that Equinox above an OSGi
platform
> would create a much-needed synergy in the Java community.
>
> Another advantage would be the separation of concerns between Java
> components and plug-in specifics. If Equinox would be a plug-in container
> above an OSGi foundation, an Equinox plug-in would be an OSGi bundle that
> defines extensions or extension points. The Java imports and exports are
> expressed within the bundle manifest. The extensions and the extension
> points are expressed in the plugin.xml, as an extra manifest without the
> "require" and the "runtime" tags.
>
> It is interesting to point out that OSGi and Eclipse have taken two
> different routes to control exports. An OSGi bundle specifies its exports
as
> a list of Java packages, all other packages are private. Eclipse by
default
> exports all Java packages from a plug-in but allows for a filter. I am not
> sure one mechanism is essentially better technically. However, I always
felt
> that a full encapsulation as a default policy is better, forcing explicit
> exports when needed.
>
> Another difference between OSGi bundle and Eclipse plug-ins is the
> encapsulation promoted by OSGi. OSGi promotes a strong separation between
a
> bundle interface and its implementation. Nothing really enforces it,
except
> for the default of private packages, forcing explicit exports. Also, it is
> stressed all over the specification. Additionally, the service-oriented
> paradigm helps to reinforce this. Eclipse tends to have a more permissive
> approach.
>
> One very important difference between OSGi and Eclipse is on dependencies.
> OSGi expresses dependencies on imported packages (name and version), but
not
> on which bundle actually exports them. In other words, in OSGi, any set of
> bundles can replace another set of bundles as long as the Java packages
they
> export are the same (name and version). In Eclipse, dependencies are
> expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
> providing no separation between a plug-in API and its implementation.
>
> Another interesting property of OSGi is its ability to support hot-code
> updates. In other words, OSGi supports the dynamic loading/unloading of
> plug-ins, with minimal impacts on the running platform. To my knowledge,
> OSGi is one of the most advanced framework supporting dynamic
> loading/updating/unloading of Java software components. This is clearly a
> missing functionality in Eclipse.
>
> This is an important point regarding how dependencies on expressed. In
OSGi,
> there is great freedom in updating or replacing bundles as long as the set
> of exported packages remains the same. This is very interesting when doing
> hot updates, where a new provider of a library or a service can be
> substituted for the currently installed one. For instance, it would allow
a
> real player bundle to replace a windows player, assuming they both provide
> the same API to play rich media. In Eclipse, this is not possible.
>
> Because OSGi is often confused with an end-to-end deployment
infrastructure,
> it is often believed to conflict with Eclipse features. OSGi does not
> conflict with the Eclipse features because OSGi does not specify a
> deployment infrastructure at all, not even an update policy.  As far as I
> can tell, features, plug-ins, and fragments can all be managed above OSGi
> bundles, leveraging the local administration API. A side efect of this is
> that OSGi does not improve Eclipse management of feature-level
dependencies
> and feature management.
>
> Here is another very interesting side effect of considering Equinox as a
> plug-in container above an OSGi platform. By moving the update manager as
a
> administration-aware bundle, I believe we improve the overall robustness
> regarding installing new software components or updating already installed
> ones. Eclipse is somehow weak in resisting install failures since the
update
> manager depends on most of the platform to be able to come up... Not very
> robust when the configuration is screwed up and needs repair, but Eclipse
> can't come up and the update manager is therefore unavailable.
>
> By decoupling the Java foundation for software components and the plug-in
> container, one achieves less dependencies for the update manager. The
update
> manager moves down to the OSGi layer, being a regular bundle with
> administrative permissions. As a bundle, the update manager could have
> minimal dependencies for coming up. None if we consider a textual
interface.
> SWT only if we consider a more graphical interface. Another avenue would
be
> an HTTP daemon and a servlet engine for a remote web interface. OSGi
> provides a very small footpring web application server suited for this.
>
> This would allow to support most configuration failures. If an SWT
interface
> is supported, we can still integrate the update manager in the workbench,
> but as an option, not a requirement. Even more severe configuration or
> failures could be handled by reinstalling the platform as long as we can
> remember the configuration across full re-installs (either locally or on a
> server). Indeed, we can reinstall the core OSGi platform and installing
back
> the last configuration known to work.
>
> Another aspect to discuss is the version model. Eclipse and OSGi have
> adopted conflicting versioning model. OSGi is Java compliant, following
the
> Java versioning model. This means that OSGi imposes full backward
compliance
> between bundle versions. Eclipse on the contrary allows major releases of
a
> plug-in to break backward compatibility. This is undoubtly one of the
major
> differences between Eclipse and OSGi.
>
> A more minor difference is that Eclipse may actually load multiple
versions
> on a library... leading to have different versions of the same packages
> exported concurrently. Eclipse attempts quite complex matching between
> exports and imports, which may lead to loading only an older version, only
> the most recent one, or both. OSGi on the contrary ensures that the
platform
> will share only the latest version available of any exported Java package.
> Notice that for most plug-ins, the ones declaring extensions or extension
> points, Eclipse only loads one version and thereby follows the OSGi
> behavior. Eclipse is therefore able to potentially satisfy more intricate
> dependency situations.
>
> Another minor difference is with the order for class loading. Eclipse
class
> loading allows local classes to shadow global shared classes. OSGi has
> adopted a more robust approach where the global space of share classes
> always prevails on local classes.
>
> There are several other minor aspects that need to be discussed. One
aspect
> is about configuration data of software components.  Another is about the
> persistent data of software components. Another one is natural language
> support.
>
> One last important comment is regarding tooling. Adopting OSGi would
require
> to bring OSGi-awareness into JDT and PDE. We expect minimal impacts on JDT
> but more important ones on PDE. But tooling biggest concern is certainly a
> better support for self-hosting, OSGi bundles versus plug-ins is a minimal
> issue.
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
>