InfoQ

News

JSR 291 (OSGi R4.1) Available for Public Review

Posted by Scott Delap on Dec 13, 2006 10:24 AM

Community
Java
Topics
JCP Standards
Tags
JSR 277 ,
OSGi ,
JSR 291 ,
JSR 294
JSR 291 has been made available for public review. JSR 291 is also known as OSGi core spec R4.1. This JSR strives to:
...define a dynamic component framework including component lifecycle for existing Java SE platforms. The dynamic component model will support assembly of applications from components and support implementation detail hiding between components as well as lifecycle management of those components.
OSGi itself has been around as a non-JSR specification for some time. Open source implementations include Equinox which forms the foundation for the Eclipse IDE, Felix, and Knopflerfish. Among the key features:
  • Allows for Reusable and Dynamic Components
  • Classloading allowing reload of parts of the application.
  • Fine-grained Service concept
  • Simple Life Cycle
  • POJO friendly
  • Extremely Light-weight
  • Deploy on Java ME, Java SE, Java EE
  • Good tooling support (Eclipse)

Expert group member Niclas Hedhman broke the news of the public review on his blog. The JSR 291 website has not been updated to reflect this change yet. In the meantime the draft is available for download on the JSR-291 mail archive.

Many industry veterans are watching the progress of this JSR in comparison to JSR 277/294. These JSR's are defining the packaging of modules and dynamic deployment in respect to the upcoming Java 7 Dolphin release. JSR 291 is targeted at existing needs and Java SE platforms.  From the specification documentfor 291:

No current JSR (either complete or in process) defines a dynamic component and lifecycle solution to run on top of the existing family of Java SE platforms. However, JSR 232 does include this capability to run on top of Java ME (CDC based platforms) along with a comprehensive set of mobility services.

JSR 277 has been filed to examine changes to the static module definition to be used within the Java SE platform for Java 7 (Dolphin) and beyond. JSR 277 is targeted for specification delivery in 2H/2007 with RI/TCK delivery as an integral part of Dolphin in 2008.

This JSR aims to address the current needs for dynamic components based on existing Java SE platforms. When Dolphin becomes available, the specification lead of this JSR will either perform a maintenance release of this JSR or raise a follow on JSR to add Dolphin to the list of compatible supported platforms and to exploit Dolphin technology for static modules, as appropriate.

Concern has been raised about the seemingly overlapping nature of these three JSR's overall. In the meantime industry use of OSGi has continued to increase in application server development and frameworks such as Spring while JSR 291 has been in development.

10 comments

Reply

Votes by Corby Page Posted Dec 13, 2006 10:48 AM
Re: Votes by Corby Page Posted Dec 13, 2006 10:49 AM
looking quite promising, Spring support will also mean more adoption by Floyd Marinescu Posted Dec 13, 2006 12:57 PM
50k for the RI and TCK by Noah Campbell Posted Dec 13, 2006 3:35 PM
Re: 50k for the RI and TCK by Scott Delap Posted Dec 13, 2006 4:47 PM
Re: 50k for the RI and TCK by BJ Hargrave Posted Dec 13, 2006 6:37 PM
Re: 50k for the RI and TCK by Stephen McConnell Posted Dec 16, 2006 9:32 AM
Re: 50k for the RI and TCK by Glyn Normington Posted Dec 22, 2006 3:48 AM
Re: 50k for the RI and TCK by Stephen McConnell Posted Dec 23, 2006 11:02 PM
Re: 50k for the RI and TCK by Glyn Normington Posted Jan 4, 2007 10:19 AM
  1. Back to top

    Votes

    Dec 13, 2006 10:48 AM by Corby Page

    The best way to kill this JSR is through votes of the JSR committee. IBM, BEA, Intel, Apache, and Google should be leading the effort to vote no on future deliverables for the JSR. If I count correctly, they should only have to recruit three more 'no' votes to keep this bloat out of Dolphin.

  2. Back to top

    Re: Votes

    Dec 13, 2006 10:49 AM by Corby Page

    Sorry, to clarify, I am talking about JSR-277. JSR-291 looks like it's coming along nicely. :)

  3. I'm seeing a lot of interest in OSGi these days. I also had the opportunity to interview Adrian Colyer (Interface21) about Spring's OSGi plans and things are looking quite interesting - exposing Spring apps as OSGi bundles will be made fairly easy.

    I hope that these two competing efforts don't turn into another Sun vs. IBM + the community debate.

  4. Back to top

    50k for the RI and TCK

    Dec 13, 2006 3:35 PM by Noah Campbell

    Does anyone know if this is due to a licensing issue with the OSGi?

    -Noah
    www.noahcampbell.info

  5. Back to top

    Re: 50k for the RI and TCK

    Dec 13, 2006 4:47 PM by Scott Delap

    Could you clarify what you are referring to in reference to 50k for the RI/TCK? JSR 277 and 294 do not have implementations yet to there is nothing you could purchase. OSGi is an open Java specification. The Eclipse Equinox implementation for instance is open source and has no cost. I really can't think of any way which licensing plays a role in this debate.

  6. Back to top

    Re: 50k for the RI and TCK

    Dec 13, 2006 6:37 PM by BJ Hargrave

    The $50K in the JSR 291 filing has nothing to do with OSGi licensing terms. You can see the OSGi spec license at www2.osgi.org/Main/OSGiSpecificationLicense. Something needed to be put in the JSR filing and the $ figure was just an upper bound. I fully expect the RI will come from open source (that is, no cost). The TCK will be licensed at no cost to qualified individuals and open source organizations. Commercial users of the TCK may be charged a fee (capped at $50K per the JSR filing).

  7. Back to top

    Re: 50k for the RI and TCK

    Dec 16, 2006 9:32 AM by Stephen McConnell

    Just for reference - is it correct to assume that the OSGI does not have a formal TCK for any of its existing specifications?

  8. Back to top

    Re: 50k for the RI and TCK

    Dec 22, 2006 3:48 AM by Glyn Normington

    Just for reference - is it correct to assume that the OSGI does not have a formal TCK for any of its existing specifications?

    No, for example the OSGi Core Specification, referenced by JSR 291, already has a TCK.

  9. Back to top

    Re: 50k for the RI and TCK

    Dec 23, 2006 11:02 PM by Stephen McConnell

    Just for reference - is it correct to assume that the OSGI does not have a formal TCK for any of its existing specifications?

    No, for example the OSGi Core Specification, referenced by JSR 291, already has a TCK.


    Thank you for the clarification.
    Is the TCK available to the public?

  10. Back to top

    Re: 50k for the RI and TCK

    Jan 4, 2007 10:19 AM by Glyn Normington

    Is the TCK available to the public?


    There are three ways to obtain the OSGi R4 TCK:

    • Pay for the TCK as part of JSR 232

    • I believe the JSR 232 TCK is available at no cost to qualifying open source projects and not-for-profit organisations.

    • Pay to join the OSGi Alliance



    I expect the same to be true of the OSGi R4 V4.1 TCK for JSR 291.

Exclusive Content

Composite Oriented Programming with Qi4j

We introduce the concept of Composite Oriented Programming, and show how it avoids the issues with OOP and reignites the hope of being able to compose domain models with reusable pieces.

Dan Farino About MySpace’s Architecture

Dan Farino talks about the system architecture and the challenges faced when building a very large online community. Dan explains how a .NET product scales on hundreds of servers.

Principles and Practices of Lean-Agile Software Development

Alan Shalloway, CEO and founder of Net Objectives, presents the Lean software development principles and practices and how they can benefit to Agile practitioners.

The Maxine VM

Bernd Mathiske discusses Maxine VM, Java compatibility, swapping major VM components, research areas, Object handling, code examples, optimizing compiler, snippets, bytecode generation, JNI and JIT.

Joe Armstrong About Erlang

Joe Armstrong speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days.

The Limits of Code Optimization: a new Singleton Pattern Implementation

The java double-check singleton pattern is not thread safe and can’t be fixed. In this article, Dr. Alexey Yakubovich provides an implementation of the Singleton pattern that he claims is thread-safe.

Pressure and Performance – The CTO's Dilemma

Diana and Jim talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.

Biztalk Services in the Cloud

Cloud computing feels like a tomorrow technology. Simon Thurman shows how developers can use Biztalk to create an Internet Service Bus which can be deployed locally or in the cloud.