18

So I took some time this afternoon to finally sit down and begin reading up on the mysterious and elusive "OSGi" and its so-called bundles.

OK, so I think I get it. An OSGi "bundle" is basically a JAR with some additional manifest information. And, instead of deploying it to a normal application server (or other container), you deploy it to an OSGi server like Apache Felix. It run and then provides services to users/clients.

How is this any different than a normal EAR being deployed to an app server???

OSGi seems to be on the rise (I keep running into it!), but for the life of me I don't understand what it offers (feature-wise) over anything you can do with real-deal enterprise server like GlassFish or Spring.

I know the world hasn't gone crazy, so I'm obviously missing something. Just haven't been able to figure out what. Thanks for any help or insight!

Archimedes Trajano
  • 35,625
  • 19
  • 175
  • 265
IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756
  • I think if this was worded as "What is the fundamental difference between OSGi and Java EE" then this would be more useful and less "opinion based" – Archimedes Trajano May 11 '17 at 17:52
  • At which point one can say... OSGi is primarily container that does what CDI tries to solve (dependency injection and resolution) but does not *usually* prevent it from running when there are errors. It provides an interface [usually through command line] that would allow fixes at runtime. Java EE would require a deployment to resolve the issues. Java EE is an application stack, though it provides container services, it is only within the scope of the application (though may get injections from a server) Note though the big Java EE servers are built on OSGi now. – Archimedes Trajano May 11 '17 at 17:56

4 Answers4

26

An OSGi bundle is more of a "software module" than a "jar", "war", or "ear" file. OSGi bundles rarely provide benefit if they bundle an entire application; however, they are very beneficial in the automation and correct handling of hooking up lots of libraries.

So consider the problem OSGi attempted to solve, and you will better understand where it fits. It is the Java equivalent of the "diamond inheritance" pattern from C++. You include two libraries, which each need a common logging library, but in this case it's not because of multiple inheritance, it's because of multiple include statements.

If the two libraries both work with the same version of the common logging library, you're in luck. If they don't, then to get each library working correctly independently, you need to load two copies of the same library, each which likely uses the same name spaces (and often the same class names).

OSGi is a means of bundling which allows two versions of the same library to be loaded which use the same name spaces, the same class names, but were created at different times. It also hooks up the "right" version to the "right" OSGi bundle, preventing a bundle from using the "wrong" release of the "right" library.

Java EE does a lot, but this isn't something that Java EE even addresses. At best, project Jigsaw was working on the same problem. Where the Java EE / OSGi confusion comes into play is that most of the early adopters of OSGi bundling were those who were implementing functionality similar to some of the libraries offered in Java EE. That said, the actual container-connection framework (OSGi) had nothing to do with the bundled functionality (although some of the discovery was structurally modified to comply with OSGi bundling requirements).

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Edwin Buck
  • 69,361
  • 7
  • 100
  • 138
  • 2
    Wouldn't transitive dependency managers like Maven or Apache Ivy solve this "JAR hell" on their own? If my app depends on 2 libraries L1 and L2, and L1 depends on joda-time-1.1.jar, and L2 depends on joda-time-1.2.jar, Ivy will resolve this for me, and so long as I have both versions of joda-time in my classpath at runtime, I'm good to go. Still not seeing the forest through the trees here... – IAmYourFaja Sep 20 '11 at 19:06
  • 2
    Ivy can download the two jar files, but when it is time to compile, Java doesn't allow two differing classes to be defined in the same class loader with the same name. If you put both on the class path, the first one that satisfies the class name will return the class, regardless of whether it's the right or wrong version. So you need class loader trees dependent on specifically the "bundles" calling the class. Which means that you effectively need a way of tracking what the bundle needs, hence the manifest files and eventually a "framework" aka Jigsaw or OSGi. – Edwin Buck Sep 20 '11 at 19:10
  • Ok....so OSGi basically addresses namespace issues by providing a suite of specialized classloaders. So if you are lucky enough to have a dependency graph where no two libs ever depend on the same jar (or same jar different versions) then you don't need OSGi. Otherise, it seems like a pretty essential tool. Is this a good assessment. Also, if OSGi is only now just on the rise, how have Java EE apps existed for this long without addressing this problem? This is kind of major! – IAmYourFaja Sep 20 '11 at 19:16
  • In the past JEE implementations either managed to address in committee a standard API interface (and have multiple implementations of said standard interface), or libraries managed to have different roles (so they didn't conflict due to name spacing), or library writers didn't get lazy with backwards compatibility. It's not too often that you need (to verify correct functionality) 1.0.5 and 1.0.7 of the same library loaded at the same time (to satisfy two other libraries' dependencies); but, if you include enough 3rd party stuff, eventually it does happen. – Edwin Buck Sep 20 '11 at 19:32
  • @Mara, just a small note to mention where Java still works without needing a OSGi solution. If all the 3rd party libraries need the same version of the same library, then you're guaranteed to work without anything "extra" in the Java class loader. OSGi addresses the "two libraries need the same class, at different versions" problem, not the "two people need the same class problem, at the same version" problem. – Edwin Buck Sep 20 '11 at 19:38
  • 1
    Few other things OSGi provides besides isolation are service discovery and dynamic reloading of individual services (without restarting the application). There are also a bunch of additional facilities described in the OSGi Compendum (standard configuration, management interfaces, etc.) – ddimitrov Sep 20 '11 at 21:15
  • Java EE provides this "feature" at runtime implicitly as well via classloading hierarchies.. Weblogic has like 3 layers of where you can load the same library and tell your "module" or app or bundle or ear or whatever which one to load at runtime, so your claime that java ee has nothing to address this problem is false even at the time of writing, because the features that I'm talking about have been available at least since 2008 and probably earlier. – niken Jul 31 '17 at 20:21
  • 1
    @mamakin Sorry to tell you this, but a JEE class loading hierarchy will stop as soon as the class is found. The hierarchies there are not hierarchies constructed so one "include statement" can pull in one version of the library while another "include statement" pulls in a different version of the library. – Edwin Buck Jul 31 '17 at 23:38
4

Comparing Java EE with OSGi is like comparing apples and oranges with the additional bonus of not knowing what is what.

Java EE focus is on scalable multi-tier business applications in heterogenous environments and enterprise wide integration of information systems.

OSGi started at another corner by integrating several independent codebases into one JVM (please excuse me for being extremely brief).

Of course some problems (e.g. hot deployment) are common to both environments - but to a varying degree.

Of course you can upgrade, downgrade and crossbreed both of them and they will meet somewhere in the middle.

So the question should not be "What benefit has A over B" but something like "In what field A has clear advantages over B and vice versa?" Let me rephrase that: "When do I need a hammer and when do I need a saw?"

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
A.H.
  • 63,967
  • 15
  • 92
  • 126
2

I'm sorry but ALL answers here are completely laughable. Dependency version issues solved with OSGi? Pooooohlease.... Ever heard of class loader policies in app servers?

OSGi seems like an idea to keep selling new books and training, while the functional needs have been covered for eons by the JAR/EAR packaging & deployment in JEE. Those who buy into it simply never got to understand how they're being manipulated. There's also a question of trends and fashion. I.e. non-engineering considerations that are a shame to this industry.

Reinventing the wheel is profitable because there are tons of fools out there. Unfortunately, there are tons of management-type simpletons who want to be on the "bleeding edge of technology" who will gladly fund their employees' courses, absorb the learning curve, and then pay through their nose in "re-engineering" of things that had nothing wrong with them to begin with.

It's not a question of "am I to use a screwdriver of a hammer". It's more a question of "hey boss, there's this new thing out there called HEMMAR, and it's really cool!". "Isn't it a HAMMER?", "No no, it's waaaaay better, it's a HEMMAR, it's for driving nails into boards, it will revolutionize the world".

Tomasz Jankowski
  • 47
  • 1
  • While sorta off topic (functionally) this is the best and most correct answer here, difference being you either *pay* for a jee "container" or download and install one for "free" in your org and learn to use it properly. – niken Jul 31 '17 at 20:27
  • 1
    Enterprise applications by nature evolve. You do not produce enterprise application on day 1. JEE classloading policies a real nightmare to manage when you have 1000 of modules and they all have to work together. JEE module can only be an EJB, MDB. RAR or WEB what about a single JAR? How about Downtime if you want to update even a single module...No phasing! So Pooooohlease JEE is no way near what OSGi is solving! – SJunejo Nov 22 '17 at 15:32
2

Most of the major benefits, at least the reasons we use OSGi, are listed at http://karaf.apache.org/, notably the first two.

Additionally, the OSGi alliance has a long list of benefits: https://www.osgi.org/developer/benefits-of-using-osgi/.

Lonzak
  • 9,334
  • 5
  • 57
  • 88
Tony
  • 2,473
  • 1
  • 21
  • 34
  • 1
    It's worth adding that an OSGi bundle is not a "full" application but rather a sub-component that can be used by any other bundle, the collection of which compose an application. – Tony Sep 20 '11 at 19:24