ZeroTurnaround Blog

Product Updates, Company News & Fun

JRebel vs OSGi: Use the right tool for the right job

Often when discussing OSGi at events, conferences or forums, we hear things like, “Yeah, I like JRebel but now we are using OSGi”, or “Does JRebel support OSGi”, or “Isn’t OSGi the same as JRebel?”. Sometimes it happens that people start comparing OSGi to JRebel, which is kind of like comparing a Ferrari to a Skyscaper; thus, this article is designed to a) explain the differences on a technical level what JRebel and OSGi do, b) outline some ideal use cases for OSGi and JRebel c) clear up any grey areas or misconceptions between the two technologies. So, let’s go!

What is JRebel and what is OSGi?

JRebel is an anything-Java plugin that speeds up JVM-based development (Java, Scala, Groovy) by reloading changes made in your workspace into a running JVM, without restarts or redeploys, maintaining the state of the application while you’re coding.
In plain speech: When developers use JRebel, they see their code changes instantly without restarting anything, keeping their flow and maintaining state; JRebel supports various IDEs, app servers and over 40 Java frameworks.

OSGi
is a module system and a dynamic runtime where modules (also called bundles) can come and go, but your code has to conform to the requirements of the module system — it is perhaps the only widely used framework for the JVM that enforces real modularity.

In plain speech:
 OSGi projects are inherently more modular than plain Java projects, as long as you follow the rules — for example, to use classes from another module, that module needs to declare that it exports the packages containing those classes.
Bottom line: JRebel is a productivity enhancer for anything Java, while OSGi is at its core a rather strict module system.

If JRebel and OSGi are  so different, why do people compare them?

Probably because both JRebel and OSGi are capable of fast or instant class reloading during development. However, with JRebel this is the pure goal, whereas with OSGi this is more of a side-effect. In the end, using OSGi means switching to a brand new framework, while JRebel quickly plugs in to your existing stack.

JRebel instantly reloads changes you make to class structures (e.g. adding/changing/removing methods, constructors, fields, classes, annotations, static field values, interfaces, etc.) so that you see immediately what your code changes look like, regardless of IDE, application server or frameworks.

In OSGi, modules can, in certain cases, be stopped, reloaded and started again with hardly any noticeable downtime. But if that module has dependent modules, this will cause a cascade effect of reloads. (JRebel monitors all of the code in your workspace and automatically reloads changes to it in less than 1 second)

What should I know about OSGi?

OSGi is the most well-known system for enforcing modularity on the JVM — tools like PDE and BndTools will validate the module boundaries and their dependencies as you edit, and your code will not run under an OSGi runtime if it tries to ignore the boundaries.

The OSGi Alliance claims that the 11-year-old framework and the enforced modularity will yield benefits such as ease of component reuse, reduced complexity (if your system already has complex dependencies), ease of deployment, dynamic updates, resilience to change, proper versioning, escape from JAR hell, simplicity etc.

Some of these claims are facts, but may or may not apply to your specific case. Others can be debated, and people have. There are both success stories and not-so-awesome stories about implementing OSGi.

It increases modularity and dynamism

OSGi can benefit your project under the following circumstances:

  • You want more modularity because you have:
    • a complex set of dependencies
    • lots of reusable pieces
    • customizations of your software in different contexts
    • a chaotic mess of a system that needs some order introduced into it
  • You want more dynamism because:
    • you want to be able to install and uninstall services or plug-ins into a running system

Not every system meets the description, and if you don’t feel the need for any of it, it’s unclear whether OSGi will help you or actually introduce more complexity than it removes. Of course, each individual case is different.

It can dynamically reload changes

Because the OSGi runtime is dynamic, where bundles can be installed, started, stopped and uninstalled, it is possible in some cases to simply stop a module, reload it, and start it again. Of course, if other modules depend on the reloaded module, they will have to be stopped and rewired to the new version as well.

It is perfectly reasonable for some expert users to find that OSGi’s reloading capabilities suit them just fine and don’t need to be complemented by JRebel, but it requires conscious effort to achieve that.

It’s worth considering that if bundles have internal state that is not restored at start-up, reloading them will lose that state. This means that when you’ve filled a form, navigated to a new page and then reload a bundle, you need to take these steps again…and your program state gets nuked during the reload.

Recreates classloaders

OSGi’s runtime is very much based on classloaders – each bundle gets it’s own classloader, with references to classloaders of other bundles – the module’s dependencies. OSGi handles reloading by dropping the entire module classloader and creating a new one – it does not reload single classes or try to preserve their state.

JRebel has a lot to do with classloaders as well – it hooks into existing classloaders to make the classes loaded through them instantly reloadable (while maintaining state), and this works with or without OSGi.

So can I use JRebel and OSGi together?

OSGi and JRebel are not directly comparable nor competing with each other. There is a small overlap as both allow some form of reloading code in a running application, but for most uses of OSGi that is a side effect more than a goal. For JRebel, it’s the main feature.

JRebel does support reloading in OSGi applications, so there is a way to use both together. Ideally, you could let JRebel reload most changes to code in a bundle, and let OSGi reload the entire bundle if changes become larger e.g. if a dependency was added, or the bundle’s activation sequence was modified.

We’ve already seen that OSGi is concerned with your application’s architecture as well as design, and requires both effort on your part and a whole ecosystem around it – you can’t use third-party libraries unless they have been „osgified“ either by the original library developers, someone else, or you.

JRebel doesn’t concern itself with modules, and is meant to be transparent. It is a single plugin that tries to stay out of your way and make Java as fast as a scripting language. JRebel is only concerned with reloading your code and static resources, whatever existing Java technologies you are using — you don’t need to change anything about the way you and your team is developing.

With JRebel, you only need to spend a few seconds providing a mapping from your running application to resources in your workspace, where the changes are made during development. And even this mapping can be generated by Maven or IDE plug-ins in most cases.

What should I take away from this?

To put it bluntly, implementing OSGi should be done when the end goal is to achieve modularity and dynamism, but this requires continuous effort on your part; using JRebel is about increasing productivity by making Java as fast and iterative as Python, PHP or Ruby. It just requires download and pressing a couple of buttons in your IDE.

Perhaps you shouldn’t go for OSGi in a new project if all you expect to gain is increased productivity through quick code reloads. OSGi is made for projects that require a highly modular architecture. Regardless of your needs, JRebel can help you in either case.

  • Umair

    I have never seen people using OSGI for increasing productivity with class reloading stuff.

  • http://twitter.com/MichaelPtrGower Michael Peter Gower

    Great article!  I had heard of both OSGi and JRebel before, but this really clarified what each is all about.  Reading it made me wonder how Maven and OSGi are related (since each deals with versioning), and it turns out that you can use both of those technologies together as well.

  • http://www.zeroturnaround.com/ Toomas Römer

    A similar article about OSGi and Maven would be cool. I’m sure you can use Maven to build OSGi modules but does the maven module system itself internally use OSGi or something else?

  • Rafał

    I’m wondering if JRebel has a plugin in stock that would cooperate with OSGi framework in such way that it would update classes and resources in the bundle’s classloader but would trigger bundle redeployment whenever the manifest, activator class or declarative services config files were modified. 
    I imagine that Eclipse + Bndtoos + Maven/m2e + Felix + JRebel would rock big time as OSGi development environment

  • Rafał

    No, Maven does not use OSGi internally. It is build upon Dependency Injection / Inversion Of Control container called Plexus, and it uses Classworlds package to maintain classloader hierarchy. Modules (plugins) and components have well defined namespaces, version schemes and dependencies and multiple versions of a component may coexist in a single runtime in separate classloaders. 
    As you see the design goals are similar but the infrastructure developed over the years independently of OSGi.

  • Jeti789

    Rafał  wrote:

    “I’m wondering if JRebel has a plugin in stock that would cooperate with
    OSGi framework in such way that it would update classes and resources in
    the bundle’s classloader but would trigger bundle redeployment whenever
    the manifest, activator class or declarative services config files were
    modified.”

    This is exactly the point. If they have this for web server development and everything, next thing would be to have this for OSGi

  • Frank Lyaruu

    I think combining OSGi and JRebel would be redundant. Either JRebel would just update the bundle, which is pretty trivial in OSGi (the command console can do that, the web console can do that, Eclipse can do that), or, you’d use JRebel to individually reload *parts* of OSGi bundles, which would only gain that you don’t have to redeploy an ‘entire bundle’ in OSGi, but redeploying a bundle in OSGi is both lightweight and fast.

    JRebel is a great tool for reducing the reloading pain of existing applications, OSGi is a way to redesign your application to prevent it. On the other hand, JRebel is easy to adopt, redesigning your app to use OSGi can be a painful experience.