It must have been 1996 when I explained to Ralph Johnson that I liked Java over Smalltalk because it was so small and simple. He looked at me warily and said: "wait a couple of years, it will grow". Ralph is a wise man and after a few years when Java grew from a handful of packages to hundreds of packages I understood what he had meant.
I was reminded of this conversation when I read a blog that compared HK2 with OSGi. HK2 was simpler because it had only 50 classes (!) and only a few pages of documentation. To be honest, I had not yet heard of HK2 so I investigated. This turns out to be the Glassfish module system developed by Sun. From the blog you get the false impression that OSGi is the Goliath spec of thousands of classes and HK2 is this new little David that has a more human size.
Interestingly, it is more the other way around, despite their immaturity. Their module/life cycle layer is comprised of 30 classes, their service/component layer is 20 classes. Security is absent. The only mandatory package in OSGi is org.osgi.framework, which is comprised of only 25 classes and contains the security, module, and service layer. Realistically one should add Package Admin, which adds another 3 classes. Still significantly smaller than the 50 classes of HK2, and they have only just started while we have been around for 9 years and had to address all the hard problems that happen when you build real life applications for constrained environments. All the other classes in the OSGi specifications are optional, when you have a specific problem we might have a specification that addresses that problem, when you do not care, just stick to the framework.
HK2 stands for Hundred Kilobytes Kernel. I guess this is something similar as the 1 dollar stores that over time become extremely creative or outright deceit because this (artificial) limit is not maintainable. I am not sure where they are today, but I am pretty sure that HK2 will require more than 100K within 2 years if they want to do it right, the real world tends to be quite messy.
Anyway, for a specification the code size of the implementations is a bit different. OSGi R3 can be implemented in less than 100k, look at Concierge. However, R4 likely requires a larger implementation because it addresses so many more use cases. Apache Felix and Knopflerfish are around 250K and Eclipse Equinox is around 900K. Why is Equinox so big in comparison? Well, their non-functional requirements state that they must be able to handle 5000 bundles. To make such a gigantic system work, they need to revert to many optimizations and caching techniques which add complexity. This difference is one of the best illustrations why the OSGi specifications are important. Depending on your needs you can choose to use Felix, Knopflerfish, Equinox, or a commercial implementation. Each implementation has made trade offs that you can match against your requirements. However, they all over the same basic OSGi environments and most bundles run on all systems.
Comparing the documentation of HK2 and OSGi it is the other way around: OSGi is bigger. The core OSGi framework specification with the optional system services is 288 pages. I agree it is a lot easier to read the 3 web pages and the Javadoc of HK2, but does it help you when there is a problem? It is interesting how the size of the documentation can be used against you. Yesterday, on the Python list someone asked if there could be an OSGi for Python and the reply was a joke about how "impressed" he was with the 1000 pages of the specification. To set the record straight, all the OSGi specifications combined comprise a 1000 pages but the core is less than 300 pages including the Javadoc. This is still a lot of text but we really tried very hard to make them as readable and usable as possible. So what do you prefer? A handful of web pages or a detailed specification. I can only defer to another wise man: "Things should be as simple as possible, but not simpler".
Peter Kriens
Hi Peter,
ReplyDeleteI'm glad Java has grown. It means that I can usually find something in the API to help save me re-writing that code that gets written over and over. If you use a language which does not have an extensive API then as a company (or an individual) you tend to build libraries of code that you think you might re-use (and often don't).
So... do you think OSGi will grow?
I've only jumped on the band wagon recently and really love it. But I feel as though I have come on board at about the same time as I came on board with Java so many years ago. OSGi feels about the right size now but I am sure there is room to accommodate more use cases. I fine with this though, because I feel I can track the additions that will be made from here on in. However, new comers to OSGi may find it overwhelming when we get to r5, r6 or beyond. For example the Java API added logging relatively recently, but by then a lot of people are using Log4j (or similar). Newbies will pick up these practices from their peers and may not be aware of the logging API for sometime.
As for OSGi's documentation, I think it's great. It really is clear to understand and helped me get up speed very quickly. I'm sure I still have lots to learn, but the detailed specs have helped me to hit the ground running rather than spending hours of trial and error.
I also especially appreciated the Best Practices PDF that was circulated on the internet recently. That has already saved me a lot of time and future maintenance troubles.
Too many open source projects with potential just have a few web pages of description and expect people to be able to hit the ground running. It is almost as if the IT community has forgotten the value of good documentation.
Thanks,
Chris
Hi,
ReplyDeleteDo you think that the .Net framework would be a viable platform to implement OSGi upon?
Will OSGi grow? Yes, but not much in the core. The current crew that makes the specifications is extremely sensitive to bloat and we have disappointed many by refusing to add their pets. There is a strong feeling that the core should only be extended with enablers.
ReplyDeleteIf you look at the OSGi specifications there are virtually no convenience functions, almost all code is there to allow multiple implementations, convenience functions can be built upon this foundation.
However, we will clearly add more optional services, that direction has almost infinite potential.
Thanks for the compliments, very much appreciated!
About .NET, there has been research in this direction and that showed that we could not combine two key features of OSGi. The first being the possibility to unload a bundle, second the ability to communicate over services with zero overhead, i.e. direct method calls. If you want to unload code, you must use a process for each bundle which makes any method call to another bundle an interprocess call. If you load assemblies in the same process, you can not unload them ...
We are working on Universal OSGi which will still require Java but will allow the service registry to be reused between .NET and Java. However, this is still in its infancy.
Kind regards,
Peter Kriens