<@U0F3291QE> as far as I remember, OSGi has quite ...

# tornadofx

[alex]

@edvin as far as I remember, OSGi has quite a few flaws, and some of them (like broken lifecycle or dependency management not working in complex cases) are beyond repair capabilities. Is this technology still used for the new software?

[carlw]

I actually think it's made for the complex cases. If there's a problem with its adoption, it's probably that it doesn't handle the simple case as simply as it could. I used it with a product called Talend ESB and it worked well to stand up message-based services.

[carlw]

Not sure of its relation to the new modules though since my experience predates Java 9

[alex]

I don't have OSGi experience beside Eclipse RCP, which is inevitably inherited by the product based on this platform. I happened to listen a presentation about OSGi issues, and overall it looks like it works, but sometimes it doesn't and it's programmer task to deduce the reason and manage workaround, because OSGi can't handle what's promised.
Just wondering if it's used in day to day projects, or it fits large-scale only solutions.

[alex]

Java 9 modularity (jigsaw) seeks different goal, they sound similar, but that's all. OSGi offers runtime modularity and hot-replace of modules, while jigsaw makes sure everything is ok at compile time (and that's why it can throw away unused modules)

[edvin]

The OSGI spec is good. Not all implementations are equal though. I know of no gaping flaws in the spec, and plenty of implementations behave very well. It is as @carlw said - it's made for the complex cases. The module system in J9 is completely static and only offers as very small subset of the features of OSGI. For applications where services can come and go it might still make sense to use OSGI. There is no better spec to do what it does IMO.

[carlw]

What I mean by Java 9 vs OSGI is that they both define a module with dependencies. Java 9 modules don't give you a start/stop hook for example