3 ms·
> So please convince me of a use case for OSGI. Imagine you're build a "platform" into which other people can load their own code. Examples include IDEs but al
by needusername 9y ago
> So please convince me of a use case for OSGI.
Imagine you're build a "platform" into which other people can load their own code. Examples include IDEs but also ci servers, static analysis platforms, CMSes, repository managers, build systems, …. The code people can load takes the form of "plugins". These plugins are written by third parties that you do not control.
That plugin code should be able to use APIs that you offer but you want prevent the plugin code from accessing your internals because you want to be free to change your internals without breaking the plugins. In addition you would like to isolate these plugins as much as possible. One plugin should be able to use one version of a library with a different plugin being able to use a different version of the same library without conflict.
While I do agree that OSGi is a bad fit for the JDK I also believe Jigsaw is a bad fit for applications because Jigsaw is constrained by the requirement that it has to work for the JDK.
> It should be noted that IBM is heavily invested in OSGI and thus its not surprising they're objecting everything that intersects with OSGI's terrain which is pretty wide.
While true I believe IBMs objections are much more nuanced and center around the unfortunately still ongoing immaturity of Jigsaw. With new features being introduced or dropped on an almost weekly basis after we're officially feature complete since 11 months I believe they have a point.
> I believe it's also heavily used in Eclipse, but then this isn't good advertising for OSGI either, as getting into Eclipse internals is such a PITA that its almost easier to code an app from scratch.
I have trouble following this argument.