JSR 291 Dynamic Component Support for JavaTM SE
2006-02-27
IBM, together with the Apache Software Foundation, BEA Systems, Inc., Intel Corporation, Nokia, Nortel Networks, Richard Hall, SAS Institute, Inc., and undersigned have submitted a new JSR: JSR 291: Dynamic Component Support for JavaTM SE. This JSR will bring the OSGi dynamic component model into Java SE. At last, I have been advocating such a JSR inside the OSGi for more years than I care to remember. The OSGi Service Platform is a Java specification; not having a JSR for this crucial specification is seriously hindering its adoption
A little known fact is that the OSGi Service Platform did start out as one of the first JSRs: JSR 8: Open Services Gateway Specification. In 1999, when the JCP first got started, we were asked by SUN to run the process according to the JCP 1.0. This caused a lot of discussions because of the intellectual property rules. Some members of the Connected Alliance (the predecessor to the OSGi Alliance) felt that the JCP gave SUN unfair power over the specifications that were to be developed by the whole group. After lots of deliberations it was therefore decided to develop the specifications inside a new organization that would have equal and fair intellectual property rules: the OSGi Alliance was born. Unfortunately, this meant we had to exit the JCP, though SUN remained as a member and provided some significant contributions.
Since then, many things have changed. The JCP is now a crucial force for Java. In this cacophonic world, JCP has become for many developers a minimum requirement relevancy. The OSGi Alliance has also changed course, in the beginning we were about residential gateways. Today, we can provide a comprehensive component model that significantly reduces the complexity of application development and can therefore take applications to new levels of functionality. What also changed was the success of JSR 232. This JSR showed us that the JCP and the OSGi Alliance can successfully work together.
Back to JSR 291. Why is this JSR so relevant for Java SE? The simple answer is size. Applications get more and more bloated because of today they include so many features. Features, that are often never used by the users. A component model reduces coupling and therefore allows applications to be delivered in separate parts instead of a big blob. An interesting example is Java itself. The current evolutionary model of Java of adding more and more packages is becoming cumbersome, even for todays roomy desktops. One of the reasons for a monolithic approach has always been the portability of applications: Write Once, Run Everywhere. This model is breaking apart due to the breadth and depth of Java. Providing Swing on a headless device is a waste of precious resources. A component model could solve this problem because missing functions can be downloaded and installed on demand. Such a component model will make it easier to include a much wider range of Java standards; only standards that are actually needed are downloaded. Currently, what to include or not to include in a language release is a very serious question because of this size constraint. Just like it is for large applications.
In the past 7 years, we have shown that the OSGi specifications have tremendous value for developers, as is demonstrated by the widespread adoption from embedded, desktop, to server applications. However, wider adoption is hindered by the fact that these specifications are not part of the JCP. I think that JSR 291 will bring the OSGi specifications under the attention of a broader range of Java developers. However, best of all, the OSGi Service specifications can provide a component model to Java that it so urgently needs, making Java even more competitive with proprietary solutions than it is today. I am really looking forward to work in this JSR. This JSR will be run with an open mailing list, so please tune in.
Peter Kriens
OSGi Evangelist
A little known fact is that the OSGi Service Platform did start out as one of the first JSRs: JSR 8: Open Services Gateway Specification. In 1999, when the JCP first got started, we were asked by SUN to run the process according to the JCP 1.0. This caused a lot of discussions because of the intellectual property rules. Some members of the Connected Alliance (the predecessor to the OSGi Alliance) felt that the JCP gave SUN unfair power over the specifications that were to be developed by the whole group. After lots of deliberations it was therefore decided to develop the specifications inside a new organization that would have equal and fair intellectual property rules: the OSGi Alliance was born. Unfortunately, this meant we had to exit the JCP, though SUN remained as a member and provided some significant contributions.
Since then, many things have changed. The JCP is now a crucial force for Java. In this cacophonic world, JCP has become for many developers a minimum requirement relevancy. The OSGi Alliance has also changed course, in the beginning we were about residential gateways. Today, we can provide a comprehensive component model that significantly reduces the complexity of application development and can therefore take applications to new levels of functionality. What also changed was the success of JSR 232. This JSR showed us that the JCP and the OSGi Alliance can successfully work together.
Back to JSR 291. Why is this JSR so relevant for Java SE? The simple answer is size. Applications get more and more bloated because of today they include so many features. Features, that are often never used by the users. A component model reduces coupling and therefore allows applications to be delivered in separate parts instead of a big blob. An interesting example is Java itself. The current evolutionary model of Java of adding more and more packages is becoming cumbersome, even for todays roomy desktops. One of the reasons for a monolithic approach has always been the portability of applications: Write Once, Run Everywhere. This model is breaking apart due to the breadth and depth of Java. Providing Swing on a headless device is a waste of precious resources. A component model could solve this problem because missing functions can be downloaded and installed on demand. Such a component model will make it easier to include a much wider range of Java standards; only standards that are actually needed are downloaded. Currently, what to include or not to include in a language release is a very serious question because of this size constraint. Just like it is for large applications.
In the past 7 years, we have shown that the OSGi specifications have tremendous value for developers, as is demonstrated by the widespread adoption from embedded, desktop, to server applications. However, wider adoption is hindered by the fact that these specifications are not part of the JCP. I think that JSR 291 will bring the OSGi specifications under the attention of a broader range of Java developers. However, best of all, the OSGi Service specifications can provide a component model to Java that it so urgently needs, making Java even more competitive with proprietary solutions than it is today. I am really looking forward to work in this JSR. This JSR will be run with an open mailing list, so please tune in.
Peter Kriens
OSGi Evangelist
Feel free to subscribe here.
Glyn Normington
JSR 291 Spec. Lead