OSGi Blog
Wednesday, December 26, 2007
Two Thousand and Seven
It is again at year's end. A few more days and the year 2008 will start. What did we achieve in this year?
Wednesday, December 12, 2007
JSR 294 SuperPackages Revisited
Some of my questions about JSR 294 have been answered by Alex Buckley from Sun. I have updated the existing blog to not hide that I had some misunderstanding. If you're interested in 294 it might be interesting to take a look at these changes, I definitely started to understand 294 better, though I am afraid to say that it did not improve my feeling about it. So please read again and watch the [] for changes.
JSR 294 SuperPackages
Peter Kriens
JSR 294 SuperPackages
Peter Kriens
Monday, December 3, 2007
JCP, or What?
In my vanity I subscribe to Google Alerts on my name. This morning it pointed me to the blog of Stephen Colebourne. Stephen argues against the JCP for many of the same reasons I have, (guess that is why he quoted me so he popped up in my vanity alert). Stephen makes some very sensible proposals. However, some comments posted on the blog are a bit worrying. Yes, I agree the current JCP is bad because its owner (Sun) is more interested in its own interest than the interest of the Java community. Ok, it is also flawed because the process has no requirements phase and is often lead by the commercial interests of one party. However, at the core of some of the comments is a discussion of what is more relevant: an implementation or a specification?
This discussion has been raised inside the OSGi Alliance as well. Why not pick one framework implementation and put a stamp on it and name it the standard? Obviously a single implementation is simpler, what do we get from a time consuming specification process that forces people to compromise?
Well, just as obviously, people's requirements differ. Equinox is optimized for very large systems, uses lots of caching, but is therefore much bigger than Knopflerfish or Apache Felix. The best part about OSGi technology is that it still strives to write applications once and run anywhere, and it is really getting closer. An independent specification allows different implementations that optimize for a certain area.
The second advantage is neutrality. Comments on Stephen's blog make it sound that today most Java innovation takes place on the OpenJDK mailing list. I am not sure if this will create a coherent API in the long run though I am pretty sure it will create bloat because one man's holy grail is another man's unnecessary complexity. The specification process allows the balancing of the interest of several parties before it is cast. Note that the implementation freedom inherent in specifications is a good way to keep the specifications aligned, just implement if differently.
The third advantage is time. Though the slow process of standardization is often used as a negative, I think it is actually a positive (within limits). Last year we started the requirements process for Enterprise OSGi and one of the main aspects is Distributed OSGi. In the past 6 months you can see how the different parties started to understand each other's use cases and requirements and how they are not trying to find solutions that are much broader than if any of them had hacked together a solution on their own. I really think that most of the OSGi specifications actually reflect this focus on industry wide solutions and not trying to solve a small acute problem under great time pressure.
The fourth advantage is the whole struggle with intellectual property rights (IPR). Life might be beautiful if everything was free, but it isn't. We live in a world where companies have legitimate rights to the fruits of their labor. Interestingly, the most free for all movement (GNU) creates the biggest problem of all because of its viral nature, affecting anything it touches. It turns out a lot easier handle the IPR issues in an implementation than in a specification because there is much less IPR involved (and therefore much less touching).
In a way, the world of creating implementations and specifications is similar to classes and interfaces. I am pretty sure no Java programmer wants to give up interfaces, the reuse of Java code would be significantly harder. Therefore, could Java be maintained by an open source community as some think? I do not think so. The language would quickly drift in a direction the hardest pushers push it into, it will bloat and become unusable for many applications.
What we need is a strong modularity layer so different solutions can compete evenly. The market can then decide which solutions work best. However, to evolve the core platform Java will need a community process, just one that is not dominated by the interest of a single commercial party.
Peter Kriens
P.S. One of the comments states that OSGi is more complex than JSR 277. Sigh. The OSGi framework API is significantly smaller counted as methods and classes/interfaces. We just have more good documentation. And obviously we cover the cases that JSR 277 will discover in the next 5 years.
This discussion has been raised inside the OSGi Alliance as well. Why not pick one framework implementation and put a stamp on it and name it the standard? Obviously a single implementation is simpler, what do we get from a time consuming specification process that forces people to compromise?
Well, just as obviously, people's requirements differ. Equinox is optimized for very large systems, uses lots of caching, but is therefore much bigger than Knopflerfish or Apache Felix. The best part about OSGi technology is that it still strives to write applications once and run anywhere, and it is really getting closer. An independent specification allows different implementations that optimize for a certain area.
The second advantage is neutrality. Comments on Stephen's blog make it sound that today most Java innovation takes place on the OpenJDK mailing list. I am not sure if this will create a coherent API in the long run though I am pretty sure it will create bloat because one man's holy grail is another man's unnecessary complexity. The specification process allows the balancing of the interest of several parties before it is cast. Note that the implementation freedom inherent in specifications is a good way to keep the specifications aligned, just implement if differently.
The third advantage is time. Though the slow process of standardization is often used as a negative, I think it is actually a positive (within limits). Last year we started the requirements process for Enterprise OSGi and one of the main aspects is Distributed OSGi. In the past 6 months you can see how the different parties started to understand each other's use cases and requirements and how they are not trying to find solutions that are much broader than if any of them had hacked together a solution on their own. I really think that most of the OSGi specifications actually reflect this focus on industry wide solutions and not trying to solve a small acute problem under great time pressure.
The fourth advantage is the whole struggle with intellectual property rights (IPR). Life might be beautiful if everything was free, but it isn't. We live in a world where companies have legitimate rights to the fruits of their labor. Interestingly, the most free for all movement (GNU) creates the biggest problem of all because of its viral nature, affecting anything it touches. It turns out a lot easier handle the IPR issues in an implementation than in a specification because there is much less IPR involved (and therefore much less touching).
In a way, the world of creating implementations and specifications is similar to classes and interfaces. I am pretty sure no Java programmer wants to give up interfaces, the reuse of Java code would be significantly harder. Therefore, could Java be maintained by an open source community as some think? I do not think so. The language would quickly drift in a direction the hardest pushers push it into, it will bloat and become unusable for many applications.
What we need is a strong modularity layer so different solutions can compete evenly. The market can then decide which solutions work best. However, to evolve the core platform Java will need a community process, just one that is not dominated by the interest of a single commercial party.
Peter Kriens
P.S. One of the comments states that OSGi is more complex than JSR 277. Sigh. The OSGi framework API is significantly smaller counted as methods and classes/interfaces. We just have more good documentation. And obviously we cover the cases that JSR 277 will discover in the next 5 years.
Subscribe to:
Posts (Atom)