Who else read RFC 124? It has a really funny title: “A Component Model for OSGi”. Yeah, that really speaks for itself. Just repeat it a few times and let it settle for a while. So, RFC 124 wants to create a component model for a component model. Funny, eh?
But is that really what people need? Maybe I just don’t get it but I thought the real problem was that programming OSGi is too verbose.
Well, I’m certainly not arguing against that. Programming OSGi is verbose. When creating services you need to write additional code to maintain their registrations. When consuming services you need to write additional code to track available services. Last but not least you need some plumbing around.
Dependency injection seems like a valid solution to make programming less verbose. Imagine you get references to your services injected magically when your object is created. You suddenly don’t have to deal with all this additional OSGi specific code anymore. Of course it’s so great that you also want it for all the other objects in your code. You want to inject arbitrary objects into your objects which aren’t necessarily exposed as OSGi services. That sounds great, doesn’t it?
What a bummer!
Suddenly you find yourself in all that XML which is even more verbose than OSGi was before. Your code is harder to analyze because a simple “ctrl+shift+g” won’t do the job anymore. You traded development efficiency for pseudo flexibility. But I’m loosing the point.
I just wanted to raise a few questions that came into my mind when reading RFC 124.
- Why must the bundle symbolic name be fixed? Why can’t it be
- Why do I need eight and a half pages of XML schema definitions?
- Why is it coupled to XML at all?
- Oh and why does the introduction start with “The OSGi Alliance needs an amended process for the creation and approval of press releases. This document will describe the process.”? 😉
I’m sorry but to me this isn’t a real RFC. It’s something that is written for a very specific implementation. It misses implementation flexibility. Frankly, I doubt that we will see any other implementation than Spring DM, which makes me kind of sad because it hurds diversity.