
OSGi After 20 Years - oweiler
https://blog.osgi.org/2019/05/osgi-after-20-years.html
======
diegof79
The article makes OSGi look like the inventor of encapsulation and interfaces,
but those concepts existed way before OSGi (from Smalltalk to frameworks like
CORBA).

What OSGi produced is a model to handle dependencies, service lifecycle, and
provisioning. But in the Java ecosystem, those features were replaced with a
mix and match of smaller projects, that are easier to adopt and use.

Instead of adapting to the community, OSGi frameworks like Eclipse Equinox
live on their own island.

Take for example provisioning: Equinox has its own framework called P2. You
don't need P2 to use OSGi. But, it's the way of doing things in Equinox. So to
share a library, you need to provide packages using a P2 update site. There is
no easy way of using Maven Repos [1]. The end result: tons of unnecessary
complexity, and more isolation of projects that relies on Equinox tooling [2].

[1]: Tycho is the solution for interacting with Maven repos; but is not easy
to setup...and in the end all the trouble doesn't pay: you end with a mix of
dependency definitions that is hard to maintain/troubleshoot.

[2]: I'm looking at you SWT... you promise a nice native UIs, but consuming
SWTs JARs from a non-Equinox project is a pain... thank you P2 and OSGi! :)

------
kaio
This article seems a bit arrogant. But I have to acknowledge that they
pioneered the trend of microservices in terms of overcomplicated designs and
slowness.

Honestly. Some of the most horrifying systems I have worked with were based on
the idea that you should be able to swap implementations during runtime. That
was the time when OSGi was _the_ thing and (like mentioned in the article)
there seem to be only a few how to use OSGi properly. I'm a burned child and
certainly don't have the knowledge, either ...but the blog post doesn't give a
single reason to change that.

~~~
userbinator
OSGi is essentially classic bureaucractic enterprise-ism meets OOP dogma cult,
and like all "hyperabstraction" in general, greatly decreases systems-level
understanding and macro-simplicity (critically important for things like
debugging) in order to favour micro-simplicity. To sum it up, "splitting a
system into easier to understand parts until each part is trivially
understandable causes the actual complexity to become hidden between the
interaction of the parts."

~~~
twic
_To sum it up, "splitting a system into easier to understand parts until each
part is trivially understandable causes the actual complexity to become hidden
between the interaction of the parts."_

Is that in quotes because it's a quote? If so, from where? Or is this a form
of emphasis?

~~~
userbinator
I'm not sure. Me and my coworkers have been saying similar things for a while,
and it's not really that deep of an observation. Abstraction can't always
magically make things easier. It just moves the complexity around, and often
increases it if used unnecessarily.

~~~
twic
Right, it's very similar to things i've said too, but clearly and succinctly
put!

I see a similar problem with the common preference for unit tests over
integration tests. The mistakes in a system tend to be in the interactions
between parts, not in the parts themselves, and by construction, unit tests
can't test those.

------
thanatos_dem
> Calling a nano-service has no overhead, unlike calling a micro-service.

It's statements like that which drive me crazy. It may very well have lower
overhead, but even a function call has overhead, and OSGi's overhead is not
small (at least last time I used it, circa 2012).

Remember Eclipse? Remember how, once you installed a couple of java plugins,
it'd take up to several minutes to start up? All those plugins were OSGi, via
the Equinox framework. The overhead was noticeable and severe. Contrast that
to IntelliJ, where I have it set up to support a dozen or so languages, all
with various plugins, and startup never takes more than 30 seconds. Still not
as fast as I'd like, but I shudder to think how Eclipse would manage.

I also echo a lot of the commenters here from the development perspective.
OSGi is one of the least pleasant systems I've had to write for. Some of that
comes down to Java's questionable approach to dynamic class loading, but OSGi
added a ton of cruft and complexity on top of that.

~~~
fiddlerwoaroof
Doesn’t IntelliJ use OSGi for plugin loading too? I looked into this a while
ago and it looked like IntelliJ bundles all the OSGi stuff.

~~~
lemming
No, it doesn't - it just uses a standard IoC container per plugin and some
simple classloader isolation between them.

------
4lejandrito
If anyone is interested in how a real product is using OSGi have a look at
Liferay [1].

It uses declarative services [2] with annotations to define components and
their dependencies. I am not very familiar with the underlaying tooling but
the end result is quite simple (see [3] for a simple component with 3
dependencies).

Disclaimer: I work at Liferay.

[1] [https://github.com/liferay/liferay-
portal](https://github.com/liferay/liferay-portal)

[2]
[https://osgi.org/specification/osgi.cmpn/7.0.0/service.compo...](https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html)

[3] [https://github.com/liferay/liferay-
portal/blob/5c29b7173777b...](https://github.com/liferay/liferay-
portal/blob/5c29b7173777bc951c1caa442c7ce9ea1e8600a2/modules/apps/adaptive-
media/adaptive-media-blogs-
web/src/main/java/com/liferay/adaptive/media/blogs/web/internal/counter/BlogsAMImageCounter.java)

~~~
twic
I believe that Liferay uses another bit of mirror-universe saucer tech, the
Content Repository for Java API:

[https://jcp.org/en/jsr/detail?id=283](https://jcp.org/en/jsr/detail?id=283)

This is essentially a hierarchical database - think something like an XML
document, a hierarchy of nodes of particular types with attributes according
to their type - but has a few really eye-opening features, like versioning,
and branching and merging of versions. I'm not aware of any other kind of
database (apart from VCSes!) that does that.

~~~
generalpf
I used Apache Jackrabbit (a JCR) at a previous job to store PDFs of insurance
rate manuals. We could tag them by province, line of business, whatever, and
then query it quickly. Jackrabbit is a fantastic piece of software.

~~~
HillRat
And Adobe’s AEM lives on top of Jackrabbit Oak, their next-gen JCR. For a lot
of purposes, Jackrabbit Oak makes a pretty good general-purpose headless CMS
in its own right (assuming you’re good with the JCR pragmatics).

------
yawaramin
> The reason why microservices work so well is it provides a well-defined API
> entry point into a module. The caller ... can ignore the messy details of
> how that API is implemented

Honestly, everyone just re-interprets microservices as whatever they feel
like! This particular quote is just describing modularity and encapsulation,
something that Parnas could have told them in the '70s.[1]

Microservices are about decoupling teams from each other so they can work and
deploy on their own schedule. To a lesser extent, they're about scaling
different parts of the system independently (on stacks that don't natively
support that with a sane concurrency model). That's really just it. Everything
else is hype and buzzwords.

[1] [https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-
us...](https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-
decomposing-systems-into-modules/)

~~~
vbezhenar
Why can't you decouple teams form each other with modularity and
encapsulation? I never worked in a team, but I could imagine that teams just
have some agreements about interfaces and then work independently on a single
code base but in a different classes and packages.

~~~
yawaramin
Because modules in the same codebase have an unfortunate tendency to cross
each others' boundaries. It's just too easy for them to reach into each
others' implementation classes and couple together strongly. But if they're
different codebases, there's a stronger wall between them.

~~~
mkleczek
(Micro)services and separate codebases are orthogonal. You can have multiple
separate components (libraries) implemented in different codebases and linked
as a single executable (which is actually really common).

You can have (micro)services deployed from as single huge codebase - just take
a look at all so-called monorepos.

------
liveoneggs
I had real world experience with OSGi 10 years ago and it was terrible. The
JVM still had permgen leaks from loading and unloading stuff so any OSGi
deployment was bound to just OOM on permgen eventually. My container had poor
(or I didn't understand it well enough) ways to define boot ordering and
dependencies within the services (like docker-compose's restart: always and
depends_on: stuff) so you would get service-C starting before service-A, which
would fail for unrelated reasons but the JVM would go ahead and start
listening on port 8080! Bring on the traffic to your broken stuff.

~~~
LoSboccacc
I'm in a OSGi platform today and have to say it's still a broken mess

beyond the fact that the world moved from big irons 25 years ago making this
whole exercise in in-jvm-microservices pointless, messing with the classloader
breaks most of the good things of the Java platform

classloader deadlocks? check

debugger having a stroke trying to use the correct source between all the
overlapping libraries at different version within the classloader tree? check

hot code road unable to figure out all the instances of services to replace
causing weird class cast exceptions of classes over themselves? check

having to create library projects that include interfaces from independent
services because in the OSGi tree you can't have cross dependents? check

I hate the thing with passion and move into real microservices fast enough

~~~
liveoneggs
throw it all away and get into the real thing
[https://spring.io/projects/spring-boot](https://spring.io/projects/spring-
boot)

------
finnjohnsen2
"Few people outside the OSGi even remotely understand the requirements and
capability model, and that is their loss. However, organizations that reach
the maturity level to use it will never let it go. "

I consider it a poor evangelism approach to make me feel stupid and useless.
In all honesty I tried to understand OSGi about ten years ago and failed to
understand how to get started and how my current project could benefit from
this. So we kept using maven and eventually gradle.

~~~
coding123
It isn't really a competitor to maven or Gradle.

~~~
watt
I can see how running a bunch of fat jar services each in dedicated JVM can be
competitor to running loads and loads of little OSGi components in one big
huge JVM.

~~~
h_r
Maven and Gradle don't run anything in a dedicated JVM. They're just tools to
accomplish various goals based on your dependencies: compile, package, test,
maybe deploy. Not even remotely similar to runtime module management like you
get in OSGi.

------
Moter8
We had to use OSGi in a student project for a distributed systems module.

It was a nightmare. We were basically forced to use Eclipse (instead of
IntelliJ which everybody was accustomed to). Eclipse alone was a nightmare to
use (slow, imports not founds, etc).

On the OSGi side:

There is no package manager. One team tried to set up maven but they failed.
We just loaded jars.

The manifest files were a mess. Eclipse launch configurations were a mess (had
to be re-imported after any change).

A small project which only required a backend was needlessly split into 5
parts. Over-engineering at its finest.

------
MarkMc
OSGi is what killed Eclipse. Instead of focusing on producing a fast, modern
IDE, Eclipse became a design-by-committee monster that had to support just
about any use case on the client.

------
ragerino
I love OSGi, used mostly Eclipse Equinox a lot in my previous job. Now I come
more across Apache Felix in my work. I can imagine people not liking it,
because it can be hard to learn. I used it mostly because of dependency hell
and for encapsulation of reusable components. Controlling which parts of the
component is exposed, is a very powerful concept.

About reliability, I can only say that it is very reliable. It has to be,
since it was developed to continue running, even if one of the loaded plugins
crashes. Imagine running plugins for the ABS, entertainment and navigation
system and the navigation system crashes. With OSGi the navigation system can
be restarted without impacting other more crucial components.

I hear sometimes people saying, Java modules are a replacement for OSGi. This
sounds to me a lot like saying that Blockchain can be used as distributed
storage system.

~~~
yawaramin
> Imagine running plugins for the ABS, entertainment and navigation system and
> the navigation system crashes. With OSGi the navigation system can be
> restarted without impacting other more crucial components.

This is _exactly_ the Erlang 'let it crash' philosophy. Supervisor 'processes'
(message-passing green threads) run concurrently and monitor and restart each
other as necessary.

The only difference is that this is not at the plugin level but at the process
level, a core lightweight concurrency primitive provided by the Erlang
runtime.

~~~
namdnay
Interestingly enough, this is exactly how a car actually works. All systems
have to send a heartbeat over the CAN bus, if not they are restarted.

------
beefhash
About two or three years ago, I tried to learn OSGi. But I had severe
difficulty actually getting started and understanding the intended application
model. It seems that the OSGi website links to more resources to get started
now[1], so perhaps I should give it another shot.

[1] [https://www.osgi.org/developer/where-to-
start/](https://www.osgi.org/developer/where-to-start/)

~~~
Sharlin
The documentation was exceedingly sparse at least when I had to do some OSGi
stuff a few years ago. I basically depended on Stack Overflow and obscure blog
posts to get anything done.

------
bhaak
I only have experience with OSGi from analysing the architecture of jailbroken
Kindle Touches. It's possible Lab126 didn't use it correctly, though. They
don't have a good track record (the first jailbreak for the KT was a mp3 with
html tags that were rendered unescaped by the stone age old browser which was
running as root).

The article claims "OSGi provides the type safety between modules that Java
provides between classes" but I didn't see any of that.

Just a ton of services and modules that send message around that let to so
much decoupling that you didn't have any Java language support anymore.

It looked like trying to do OO in C. You can do that but then you are
completely on your own and have to ensure everything by hand.

~~~
geodel
I have heard of so many projects inside enterprise and product vendors which
were unable to get this OSGi thing working. The answer from OSGi fans is
always in same vein: 'you are holding it wrong'.

------
mrbonner
I am looking into classloader isolation solution and it seems OSGi, especially
the Classloader specification is wonderful. The whole OSGi spec is a 400+page
book if you are into services, security, etc... but the Classloading isolation
spec is small and very useful.

I am in need of a way to allow plugins/integration with other teams. If we use
standard Java package sharing mechanism, sooner or later teams will run into
dependency conflict hell. More often, microservices (IPC) is suggested, too.
But, the nature of our application is sensitive to latency and require high
throughput. That throws IPC out of the picture.

Then, I remember the servlet API and how the servlet spec dictates
classloading isolation at the container level. I rolled my own classloader to
isolate the plugins/integrations but it is not as nice as OSGi implementation.

At this point, I am very inclined into using OSGi just for the sole
classloading purpose.

One question that bother me is: since we are not that hardcore OSGi users,
would it make sense for us to just bundle every plugins' into a fat jar and
use bundle-classpath to resolve the plugin's owned dependencies? I know that
by doing so, we are not strictly adhere to OSGi classes' sharing but it would
lower the friction for independent teams to integrate with us.

~~~
mkleczek
In my opinion the main issue with OSGi class loading is that the spec couples
three separate concerns:

peer class loading (as opposed to hierarchical)

dependency resolution

dependency specification and module (bundle) packaging

This makes OSGi an all or nothing solution: to use OSGi class loading you are
forced to package your code in a specific way - which in turn makes it
difficult to reuse existing libraries.

Lack of peer class loading has been a long standing pain point in Java - and
in my opinion one of the main obstacles for really interesting use cases -
especially related to mobile code ( see Jini ).

------
tonit
The true question is: are the values that OSGi stands for (still) reasonable?
The values are: modularity as core concept at build and runtime, low footprint
adaptive services and vendor-agnostic specification.

Now, OSGi may have a poor image in the current Microservices/cloud vendor
driven bubble. But let’s step a bit back and ask: 1\. isn’t constructing
software from building-blocks useful? What’s up with reuse, synergy, not throw
away software?

2\. Wouldn’t services be useful that don’t just die but reconfigure (adapt)
when upstream dependencies change/go away?

3\. Is time to market really the best incentive these days? What’s up with
making sure software is constructed with security and privacy in mind? What
about assuming your startup isn’t sold (sell and forget) but you need to
evolve it?

So, incidentally those qualities are part of the OSGi values made up about 20
years ago. If not OSGi (a messenger of values), wouldn’t the values make more
sense now more than ever?

What about „green“ software development?

/ Toni

------
ysleepy
What does REST have to do with OSGi? I appreciate OSGi quite a bit, bit how
does one migrate a module to a microservice without changing the API surface
to reflect new error modes that come with networking and missing transactions?

Java RMI, CORBA etc. have failed. Is OSGi somehow an RPC mechanism?

~~~
preordained
I'd call the same interface but behind that is a layer that talks to REST and
if there is some networking error that's a runtime exception. You are probably
bringing a DB at that point so I don't know if you need explicit transaction
logic. So you could have the service in the same JVM but then cut it out and
make it a microservice just by adding a REST "proxy".

------
kaidax
You can easily get the good parts of OSGi, without its cruft and complexity:
[https://github.com/7mind/slides/raw/master/02-roles/target/r...](https://github.com/7mind/slides/raw/master/02-roles/target/roles.pdf)
(by advanced DI with garbage collection)

------
jasonmp85
Frankly, their biggest accomplishment is operating in several spaces where
I've come across the abbreviation without me ever having to know what it is or
why it needs to exist (which seems to indicate… it doesn't?)

------
hestefisk
OSGi is as much micro services as CORBA is.

