File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is OSGI framework a Dependency Injection killer? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is OSGI framework a Dependency Injection killer?" Watch "Is OSGI framework a Dependency Injection killer?" New topic
Author

Is OSGI framework a Dependency Injection killer?

Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
They are different. OSGi focuses on modularization in general, while DI solves coupling issue.


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
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
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

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
Marshal

Joined: Mar 22, 2005
Posts: 41839
    
  63
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.


Ping & DNS - my free Android networking tools app
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
So how do we DI in an OGSi bundle without using DI?
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41839
    
  63
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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
Marshal

Joined: Mar 22, 2005
Posts: 41839
    
  63
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
That answers my (don't expect an answer) question. Thanks.
Like I said the answer is already in the question.
Stephane Clinckart
Ranch Hand

Joined: Oct 21, 2003
Posts: 89
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is OSGI framework a Dependency Injection killer?