Would OSGI be a good choice for developing a new large application nowadays?

[Claude Moore]

I have to help to define a back end, Java based technology stack for a mid-to-large sized new application, and a consultant suggested me to take into account OSGI. I'm not new to OSGI. I used it successfully in a particular scenario where hot deployment of self contained services was a crucial requirement, and to be honest I think I have used only the 1% of possibilities OSGI has to offer, so I don't claim to be an expert. Nevertheless, my feeling is that OSGI - besides the fact that is the backbone Eclipse is build upon - has never gained a large popularity, has a steep learning curve, and there's no so much expertise around to gather help from. My first choice at the moment is Spring, a framework that's getting more and more traction (especially thanks to Boot) and seems to dominate Java mainstream. Anyway, the fact that a framework is popular isn't itself a sufficient reason to be choosen. Honestly, documentation one could find on Spring in different forms  - blogs, technical articles, handbooks and so on - is simply numerically overhelming documentation I was personally able to find on Osgi, but this is still not a sufficient reason not to adopt Osgi. What I fear is that Osgi smells of old-fashioned technology, and it wouldn't be a smart idea to  choose it.
What do you think about , and what can you advise me ?

[Tim Moores]

I wouldn't call OSGi old-fashioned, but you're right that it hasn't exactly become mainstream. That was probably to be expected as it solves some tough architectural problems. And, before things like Declarative Services and containers like Apache Karaf came along, had a steep learning curve. Even with those it's not a trivial technology to use. But it's still being developed, as are its major implementations (Apache Felix and Eclipse Equinox) and their respective ecosystems.

In the past I have successfully used Felix for implementing a plugin solution for dynamic updates. Back then, I used the Felix and OSGi APIs directly to create my own container. These days, my choice for that would be to embed Karaf, and let it handle all the low-level stuff.

[Tim Holloway]

As far as I know, there's no plan to move Eclipse off of OSGi. In fact, I think Eclipse helped shape OSGi.

OSGi has the virtue that it allows you to effectively carve your JVM into multiple mini-JVMs, each with its own classpath and context. This is also what webapp servers do, and in fact, OSGi has been used to create webapp servers.

There have been experiments done on partitioning JVMs over the years and occasional motions towards that in the general Java language environment, but for the moment, OSGi is probably the best-known and best-supported way to do that kind of stuff.

I've got a book that's several years old now titled "OSGi and Equinox" from the Eclipse project series by Addison-Wesley that I have found useful. There's probably other, newer stuff, but I usually end up getting my documentation straight from project source websites these days. A good dead tree is easier for me to learn basics from, but, alas, usually out of date the moment it rolls off the press.

[Claude Moore]

Tim Moores wrote:I wouldn't call OSGi old-fashioned, but you're right that it hasn't exactly become mainstream. That was probably to be expected as it solves some tough architectural problems. And, before things like Declarative Services and containers like Apache Karaf came along, had a steep learning curve. Even with those it's not a trivial technology to use. But it's still being developed, as are its major implementations (Apache Felix and Eclipse Equinox) and their respective ecosystems.

In the past I have successfully used Felix for implementing a plugin solution for dynamic updates. Back then, I used the Felix and OSGi APIs directly to create my own container. These days, my choice for that would be to embed Karaf, and let it handle all the low-level stuff.

Thanks for your reply Tim. The approach to embed an OSGI framework is something I'm experimenting, there's a nice guide on Apache Felix website, and i's omething applicable even for Spring Boot without much effort. Curiously, I'm afraid it isn't so easy to convert a Spring Boot project into an Osgi Bundle.
This said, what would be your personal choice ?

[Claude Moore]

Tim Holloway wrote:
OSGi has the virtue that it allows you to effectively carve your JVM into multiple mini-JVMs, each with its own classpath and context. This is also what webapp servers do, and in fact, OSGi has been used to create webapp servers.
There have been experiments done on partitioning JVMs over the years and occasional motions towards that in the general Java language environment, but for the moment, OSGi is probably the best-known and best-supported way to do that kind of stuff.

Indeed OSGI could be a good choice for microservices based applications. I've read a couple of presentations on the web proposing this idea. Just to change the point of view : why Spring became a mainstream framework, while OSGI did not enjoy a similar success ?

[Tim Holloway]

Spring is an Inversion of Control framework. It lends itself to many different types of applications, but it is not a container architecture.

OSGi, on the other hand, is a container architecture.

Most applications either run stand-alone or in a container framework such as J2EE, and J2EE was developed before OSGi. So OSGi is primarily good for systems where you want many non-web applications running under a single control point rather than having them splattered around the OS in memory-hungry discrete JVMs. And/or you want a dynamic plug-in architecture that you don't have to roll up from scratch.

You can certainly create Spring-managed apps within OSGi, and for that matter, if memory server, there's even a subset of Spring designed to support OSGi (why not, there's a subset of Spring for almost anything.).

Back quite a few years ago I was on a team responsible for running a workflow system based on Apache Avalon. Avalon and its relatives basically fell into a black hole and it was a challenge looking for something that could serve as a similar purpose. While Eclipse was just going open-source back then, OSGi was not a well-known framework at the time. If it had been, I probably would have gone with it.

I do keep a system running on Apache Karafe on my own personal server farm. One of its applications digests emails from job sites to try and present me with remote work options (while discarding the items that say things like "No remote work"). Another pulls data from the National Hurricane Center to provide a daily synopsis each morning.

[Claude Moore]

Thanks Tim for sharing your experience and your point of view! Yes, Spring is a IoC framework and essentially an opinionated way of organizing code.About Spring managed apps within Osgi, are you thinking about Spring Dynamic Modules? AFAIK it's no longer supported or developed. Meanwhile, I had a look at karaf, the product Tim mentioned in his reply.Looks interesting and anything but abandoned.

[Tim Holloway]

Claude Moore wrote:Thanks Tim for sharing your experience and your point of view! Yes, Spring is a IoC framework and essentially an opinionated way of organizing code.About Spring managed apps within Osgi, are you thinking about Spring Dynamic Modules? AFAIK it's no longer supported or developed. Meanwhile, I had a look at karaf, the product Tim mentioned in his reply.Looks interesting and anything but abandoned.

I think so, but it has been a while. I used the Blueprint framework, which wasn't as well-documented as I would have liked, but I managed to club it into submission.

As for Spring Dynamic Modules, I found this recent post on StackOverflow:

As of 2018-MAY-14, the Eclipse Gemini Blueprint (the successor of DM) seems to be working on a new release (3.0.0) which integrates Spring 5. So, maybe not completely dead. Spring DM is used in Atlassian JIRA and in JBoss Fuse so hopefully they invest some effort to bring this on.

If Jira is using OSGi, then I don't think OSGi is likely to die very soon. Love it or hate it, Jira is a force to be reckoned with.

[Claude Moore]

Tim Holloway wrote:If Jira is using OSGi, then I don't think OSGi is likely to die very soon. Love it or hate it, Jira is a force to be reckoned with.

Oh, I never tought OSGi was going to die. Technologies that gained, at a certain point of their lifecycle, quite interest among developers, are practically impossible to kill.
VB6 programs are still out there,  now and then it happens to me to see very old Java programs still using AWT (of course, in maintenance mode).
And, as you pointed out, Eclipse is entirely based on OSGI and we can bet it's an IDE that will be around for a long time to come.

So the real "risk" in choosing OSGI  (as well as any other non-mainstream framework / architecture, for example think about Microprofile : appealing, but who's using it in production ?) is not that, at a certain point, you won't be able to achieve your goals because the tech stack you choose is legacy or too much obsolete.
The main risk is to be blamed for choosing  the "hard way of doing things", while a more comfortable one  was available.

[Tim Moores]

Claude Moore wrote:The main risk is to be blamed for choosing  the "hard way of doing things", while a more comfortable one  was available.

You mentioned considering Spring and OSGi, but those are more complementary than alternatives. Which problems are you facing in particular for which you'd consider OSGi to be a good solution?

I haven't use Spring Boot, but from what I understand it's a way to easily bundle Spring applications into separate, standalone entities. I don't know if that implies separate JVMs as well -although I think it does-, but as Tim H pointed out, that's normally something you want to avoid, and for which OSGi might be a solution - in which case Spring Boot would no longer serve much of a purpose.

[Tim Holloway]

I haven't paid much attention to Spring Boot in detail, but a lot of its initial appeal was that it made a single distributable unit containing an embedded webapp server (Tomcat or jetty) and a single (?) web application.

As it happens, a single-app Tomcat server served as the management console for VMWare once upon a time, and Spring Boot would have been ideal for that.

OSGi is a more complex framework, and in fact, a Spring Boot build that embedded something like Karafe and an OSGi app would not be such a bad concept. That said, I actually don't know if Spring Boot these days does other things besides stand-alone webapp systems. I haven't been sparing the time to keep up since no one's paying me to do so.

[Claude Moore]

Tim Holloway wrote:
I actually don't know if Spring Boot these days does other things besides stand-alone webapp systems.

More or less, Spring Boot is an opinionated view about Spring itself and about writing applications in Java. I think that all the buzz around REST Api and Microservices played a big role in helping Spring Boot to gain its momentum, and honestly building a REST Api in Spring is really simple; but Spring isn't limited to API programming.