Bogomil ShopovOften 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.