Is OSGI framework a Dependency Injection killer?

[Stephane Clinckart]

Hi,

If a project make use of OSGI repositories and split the project in small bundles... why should we still use Dependencies Injection?
With the latest GUI, it is more and more easy to manage bundles and dependencies.

So my reflection now is: why should I still use a DI framework when OSGI solve already (and better in my opinion) the dependencies problem?

I expect that the OSGI repositories will contain more and more projects, libraries, ...

The reuasability of project in OSGI repository is more efficient in my opinion.

So will DI frameworks like Spring, etc be dead in a short term???

I think so.

What de you think about???

Thanks,

Stephane

[Hong Anderson]

They are different. OSGi focuses on modularization in general, while DI solves coupling issue.

[Stephane Clinckart]

Kengkaj Sathianpantarit wrote:They are different. OSGi focuses on modularization in general, while DI solves coupling issue.

OSGI also take care about coupling...

You have to define what you import and what you export.

--> This is a kind of coupling also... managed by the OSGI Server.

Better, you can manage coupling with a version of what you are importing.

They are some pro and con... but for me, at the end... OSGI give more power than "simple ID" like Spring.
The biggest benefit for me is that you can reuse module really easilly from one to another project.
Another benefit is you can generate dependencies graph...

The overhead to build a module is not high anymore with a powerfull IDE.

Of course... it is my opinion...
I use DI dealy for more than 3 years now... and only some weeks OSGI.

My feeling is that at the end (in some years) OSGI will kill DI.

Stephane

[David Newton]

I don't see that OSGi and DI are mutually exclusive: even if you're using OSGi as the "supplier" of an implementation you still have to get the implementation into the class that needs it. Even if that's handled by OSGi it's still DI.

DI/IoC are very broad terms and are technology-neutral.

[Ulf Dittmer]

I second David in that I don't see OSGi and DI competing for the same spot. While OSGi can be used to implement a DI solution, if that's all one is interested in, I'd say that's way overkill given OSGi's overhead.

Also, OSGi only solves the coupling problem to a certain degree - the developer writing the bundles would need to write a fair amount of code to implement DI, whereas with a framework designed for this, DI is just an annotation and/or a config file away.

[Hong Anderson]

So how do we DI in an OGSi bundle without using DI?

[Ulf Dittmer]

So how do we DI in an OGSi bundle without using DI?

What difference do you see between using DI in an OSGi environment and using DI in a non-OSGi environment?

[Hong Anderson]

Ulf Dittmer wrote:

So how do we DI in an OGSi bundle without using DI?

What difference do you see between using DI in an OSGi environment and using DI in a non-OSGi environment?

I mean if OSGi can replace DI completely, how do we use DI in an OSGi bundle without using DI?
It might sound stupid, but the question has the answer in itself .

An OSGi bundle is just a collection of classes/interfaces, if within a bundle we want to use DI we have to use DI (how can it be any more obvious?).
So I cannot see how OSGi could replace DI pattern.

[Ulf Dittmer]

Using OSGi to achieve DI seems strange to me, so I wouldn't say that it can (or should, or will) replace it completely; see my first post.

If you need DI in an OSGi application, you'll either have to implement it yourself, or use a framework that supplies the required DI capabilities. I'm not sure if that addresses your question about "how do we use DI ... without using DI?", but then, I don't fully understand it.

[Hong Anderson]

That answers my (don't expect an answer) question. Thanks.
Like I said the answer is already in the question.

[Stephane Clinckart]

In my opinion... it is more usefull on a long term to use OSGI.

In the beginning there is some overhead to create small bundles...
But at the end... they are created, versionned, accessible remotly updatetable, ...

When I look the global cost of a project (from a to z)...
and if you are rigourus when creating small OSGI bundles... you are wining using OSGI vs DI framework like Spring.
--> bundles are more easilly testable, reusable, deployable, ...

So at the end... when you calculate the global cost of your project, you win using OSGI vs Spring.
And you architecture is more strong, more maintenable, ...
Of course... the project should not be a small project...
I'm speaking about serious enterprise projects...

Another benefit... when you will start a next project... lot of your bundles can/will be reused...

That is my opinion.... anyway... on a small project... you should naturaly prefer using Spring DI...
But on the long term... with lot of small projects... OSGI give more benefit in my opinion.

Regards,

Stephane