At Sunshower.io, we write software for people who write software. We’re pleased to announce something new to help folks scale their software: Zephyr, a next-generation plugin framework written in Java. Zephyr is an OSGi alternative — inspired by the best parts of it while dramatically reducing complexity and improving interoperability with existing frameworks and ecosystems.
Zephyr was born from our frustration with existing module systems. We started off using Wildfly and embedding OSGi, but this proved inadequate for the complex dependency graphs we encountered while developing the Sunshower platform. In particular, continually copy/pasting around manifests to import the dozens of packages from various frameworks was tedious and error-prone (and auto-generating them wasn’t much better, in fact). It greatly increased the complexity of our builds and deployments as we’d continually need to rev released versions of modules. This is to say nothing of the complexities of testing module interactions, or the joys of a ClassNotFoundException appearing suddenly after weeks of smooth operation caused by a forgotten Package-Imports declaration.
After over 18 months of working around framework limitations, we looked at the “Kernel” that arose from coping with these problems and decided “Hey, this is pretty useful. Let’s get rid of underlying systems and just use that.” And now we’re open-sourcing it.
Small but mighty, Zephyr aggressively and automatically parallelizes management operations while running in less than 512KB of memory. It intelligently manages all aspects of plugin lifecycle, including dependency resolution. Deploying new plugins is quick and painless. And, of course, setting up plugin dependencies for tests is, well, a breeze.
While we wrote it in Java, Zephyr works with whatever languages you normally use by installing language runtimes as plugins. You can have multiple frameworks running side by side, eliminating a lot of overhead associated with rewrites, scaling and transitioning architectures.
Zephyr is available on Github under an MIT license. Enterprise support contracts are available. Go check out the website, the docs or the repository. We’d love to have you involved!
Well, the problems you sketch impy you’re doing something fundamentally wrong with OSGi. Class Not Found Exception are a clear indication something is really bad in your system and using bnd means the manifest is invisible.
Would it not have been wise to consult an expert before you start to blame a technology and commence on the long road to make something better?
Sorry about the delay, this got flagged for some reason and I did not see it.
Sure–they’re unrecoverable exceptions that need to be fixed. The problem wasn’t that we couldn’t fix them, the problem was that we were tired of encountering them across a reasonably representative set of our use-cases.
We’re not blaming OSGi for anything–it’s obviously a fine and stable technology. What we did was identify our usage patterns, and found that they did not fit cleanly into the OSGi ecosystem for the reasons we mentioned, so we built an alternative. In particular, we realized that the issues that we encountered with OSGi were the result of a difference of resource-management philosophies: OSGi defaults to quite strict isolation with restricted opportunities and capabilities for intelligent sharing, whereas Zephyr explicitly and conveniently provides for them.
What I am saying is that if you encounter these exceptions, you’re doing something fundamentally wrong. They are a symptom that you, or one of your dependencies, is using hacks. If you use a tool like bnd, these exceptions can only happen when you tinker to do something that Java was not designed to do. All these exceptions are telling you that your code is not modular and that it is trying to bully other bundles. Yes, it is telling you that your baby is ugly 🙂
I’ve had a customer that build an industrial gateway on OSGi with an inexperienced team. After almost three year I found out during a session that none of the present developers knew what a Bundle Context was. They had never had to work with the low level details. If you follow the rules, and that is what modularity is fundamentally about: constraints, OSGi is extremely easy to use. However, if you want to roam as an outlaw over a long class path, it is a bitch. As it should be if you want to do software engineering.
OSGi has mechanisms to do controlled sharing. Either through services or the so called extender model. This all within the requirements capability model that allows you to automatically create runtimes that never run into errors like class not found exception or the corresponding wrong resource error.
The sad story is that in the 20 years of history of OSGi I’ve heard hundreds of these stories. Glassfish’s HK comes to mind. Invariably the authors tend to not understand the features of OSGi well enough but are just put off. Too much documentation to read, too many features, etc. However, today, OSGi is an incredibly lightweight, mature, technology that has very high productivity when applied as intended. The requirements and capabilities model combined with semantic versioning creates a software engineering development model that is imho unsurpassed. And I do have quite a bit of experience in our industry.
You probably hear the frustration in my voice. If I can help a company to use OSGi from scratch, I can turn them into an incredibly productive unit. The Declarative Services make programming use only domain objects. The service model is perfect to keep bundles independent from each other. The bundle model provides a deployment model and sharing of resources. The requirements capability model makes it easy to create runtimes where all transitive dependencies, and not just limited to maven like module dependencies, are lined up. And when you reach the highest level of the modularity maturity model, baselining ensures you never have a release with incompatible API.
And them I am not even talking about the magic components that are available. The gogo shell that makes it zero effort to provide commands to a very powerful shell. The Web Console that makes it trivial to provide output to a surprisingly well functioning web interface to the code. The incredible power of Configuration Admin, especially if you understand the collaboration with Declarative Services. The maturity that resulted in many components that provide extensive support for frameworks that are unattended.
Invariably when I end up in a company that has used OSGi I find many bad practices and people that don’t like OSGi. As said, OSGi is a bitch when used wrongly. And she should be to do software engineering. When we’ve cleaned up the mess, moved to Bndtools, and the developers see how it can be used, the wonder how they could ever have lived without it.
Anyway, spending too much time on this. Good luck, but if I were you I would take another look why OSGi failed for you. I do not think you really realize what you’re missing 🙂
One thing we mentioned in passing is the fact that we have a distributed Lisp dialect (known internally as Breeze) that compiles down to JVM bytecodes (dynamic classes) that must be loaded/unloaded quickly, dynamically, and across thousands of individual nodes. These programs dynamically create dependencies between each other depending on complex, self-modifying topologies. Bnd won’t help you here.
Even disregarding these edge scenarios, we do not always control the development of plugins deployed into a Sunshower.io ecosystem. We can’t train everyone who needs to deploy plugins on Bnd/Gogo/Karaf/iPojo/etc.
These issues hint at a broader truth, one that has hindered OSGi’s adoption (and I know this will be heresy for you): we don’t care about writing modular code. We don’t want to invest in training our users in any particular paradigm or toolset, nor force it on our development team because “modular code” does not solve a business problem for us or them. Users want to build modular applications without changing their toolkit (Spring, Quarkus, Dropwizard, Luminus, etc.) or their development practices which do not currently include the OSGi ecosystem and would require enormous investment to do so.
The amount of anger/frustration that the appearance of a new modular framework inspires in the OSGi community is pretty remarkable as well. So what if a new project wants to take a graph-theoretical approach to dependency management? Why are you frustrated that OSGi didn’t work for us? Don’t be–if we had the technical expertise to develop a technology that was at least as sophisticated as an OSGi implementation, we were probably pretty deep experts in the technology.
I am not the OSGi community. I am just a disgruntled old guy that got triggered by some of what you stated and had too much time. I guess, the shit I often get to see of what people call software made me that way.
I really couldn’t care less what framework you create. I’ve seen too many come and go over the past 20 years. Avalon anyone?