4 ms·

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 pr

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. Personally, I've never seen the need for something like OSGI at all. I could grok service component jars (as in SCA) with service description artifacts and manifests, but OSGI, making its way from a modular Java spec for mobile apps (J2ME anyone?) to a general-purpose server module thingy and service container was too much a projection surface for everything and anything for me. Last time I had to deal with it was years ago with Apache Camel/Service Mix and I didn't like it. If I remember correctly, it had a System V-init like directory in a .jar file which indicated run levels of an app. Obviously, replacing POSIX by a partial "100% Java" implementation can't be the use case for OSGI. 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. As I understand, Oracle wants to unbundle some Java dependencies (such as Swing/awt) from the JRE, but using OSGI for that doesn't seem to work since you must explicitly call loadBundle() or something on each and everything. So please convince me of a use case for OSGI.

needusername 10y 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.
mindcrime 10y ago
Last time I had to deal with it was years ago with Apache Camel/Service Mix and I didn't like it. Curious to know what you don't like about that stack? We use the heck out of ServiceMix/Camel and personally I'm thrilled with it. I consider it a great platform for building backend services (micro or otherwise). At the end of the day, OSGI is pretty much just Java. I mean, a bundle is a jar with some extra metadata packed in. It's not some radical departure from standard Java. I think Sun let their pride get in the way 15 years ago, when they refused to just incorporate OSGI into Java as the "official" modularity spec, and instead wasted years of time on all the various failed efforts to define a standard Java module system. And as a result, here we are all these years later, still fighting over this, when OSGI just gets the job done.
liveoneggs 10y ago
Have you ever wanted to run out of permgen really really effectively? Have you ever wanted to run a bunch of stuff inside of a single jvm and have an even harder time than normal ensuring that all of your apps are actually up and running? Do you like re-inventing wheels with concepts that were dated and overly complex five years ago? OSGI! OSGi was yet another bad architecture tacked onto java for no real benefit that over-promised, under-delivered, and wasn't even a good fit for the technology at the time. My OSGi experience comes from Day Software if that was an outlier then maybe I was just burned by them.

needusername 10y 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.

mindcrime 10y ago

Last time I had to deal with it was years ago with Apache Camel/Service Mix and I didn't like it. Curious to know what you don't like about that stack? We use the heck out of ServiceMix/Camel and personally I'm thrilled with it. I consider it a great platform for building backend services (micro or otherwise). At the end of the day, OSGI is pretty much just Java. I mean, a bundle is a jar with some extra metadata packed in. It's not some radical departure from standard Java. I think Sun let their pride get in the way 15 years ago, when they refused to just incorporate OSGI into Java as the "official" modularity spec, and instead wasted years of time on all the various failed efforts to define a standard Java module system. And as a result, here we are all these years later, still fighting over this, when OSGI just gets the job done.

liveoneggs 10y ago

Have you ever wanted to run out of permgen really really effectively? Have you ever wanted to run a bunch of stuff inside of a single jvm and have an even harder time than normal ensuring that all of your apps are actually up and running? Do you like re-inventing wheels with concepts that were dated and overly complex five years ago? OSGI! OSGi was yet another bad architecture tacked onto java for no real benefit that over-promised, under-delivered, and wasn't even a good fit for the technology at the time. My OSGi experience comes from Day Software if that was an outlier then maybe I was just burned by them.