4.3 Companion Code for Java 7

Starting in version 4.3, OSGi started to use generics in some of the API including the Core specification. Generics were introduced to the Java language in Java 5. However, OSGi needed to continue to support embedded use cases which use the CDC/Foundation 1.1 runtime which is still based upon the Java 1.4 language level and JVM. To address this issue, OSGi compiled the APIs with -target jsr14; an undocumented javac flag introduced before Java 5 was final. So we had the best of both worlds: we can use generics and still compile to run on Java 1.4 based runtimes.

This worked for Java 5 and Java 6. But when Java 7 shipped, two things changed: javac no longer understood the jsr14 option to -target and javac refused to recognize the attributes containing the generics information in class files already compiled with -target jsr14. The change to no longer support creating -target jsr14 class files was ok; we could continue to compile with Java 6 javac. But the change to the javac to cease to recognize the class file attributes with the generics information in existing class files was a bigger problem. It meant that the 4.3 API jars published by OSGi were not useable by people who need to compile with Java 7 javac. By not useable, I mean javac treated the classes as if they did not contain any generics information: they were raw. A bug was filed against Java to see if this was some mistake or oversight. The reply was that the change was intentional.

At the time this was first noticed, Java 7 was new and not too widely used. OSGi also included the source code in the jars so you could recompile the code yourself if you needed. Later, when it came time to ship Core R5, we changed to compile the API classes with -target 1.5 and so they work fine on Java 7. So problem solved; the new release's jars don't use -target jsr14! Except some of the current OSGi implementations (I'm looking at you Felix and Karaf) are still based upon Core 4.3 and thus people using those implementations still need to use the Core 4.3 API. And if they also want to use Java 7, they need to recompile the OSGi API source. So after some prodding by a few folks, OSGi rebuilt the Core and Compendium API jars as Core 4.3.1 and Compendium 4.3.1. The new jars have the same packages at the same package versions having the same API signatures. They are just not compiled with -target jsr14 so they work fine with Java 7.

So if you need to use the 4.3 API with Java 7, pick up these new 4.3.1 jars. They should also be available on maven shortly.

OSGi DevCon 2013 - Call For Papers

So with the OSGi Community Event finishing yesterday the focus now shifts to OSGi DevCon 2013.

We are pleased to be co-locating OSGi DevCon 2013 with EclipseCon in Boston, MA from March 25 to 28, 2013.

The Call For Papers is open and runs until November 19 this year.

However an Early Bird Selection of one talk for the program will be made from the submissions received by October 31.

Yes thats right, the Early Bird Selection deadline is next Wednesday. So you have only 6 days left if you want to maximize your chances of selection and get a free pass to the OSGi DevCon and EclipseCon conference.

We want to hear about experiences from speakers who have deployed OSGi based systems, large and small, as well as embedded, enterprise, or desktop systems. We are also especially keen on tools and frameworks that make it easy to build, use, and deploy OSGi-based applications along with the growing number of uses of OSGi with cloud.

To find out more about how to make a talk submission please visit the OSGi DevCon 2013 conference page.

If you have any questions please contact the OSGi DevCon 2013 Program Committee by email.

We look forward to reviewing your submissions.

Mike Francis & BJ Hargrave

OSGi DevCon 2013 Program Committee

You Need to Attend the OSGi Community Event 2012

Do you want to get more engaged, meet with interesting people, share ideas, difficulties, and successes? When’s the last time you were able to combine work and pleasure very easily? Well, there is a good opportunity on the horizon.

It’s the time of the year when the OSGi Community gets together to learn about and share new technology updates and latest business deployments, discuss technical insights and further developments. Do you want to talk about

•  Tasks to tackle?
• Why it is important to reduce complexity with OSGi?
• Why modularity is important?
• What Cloud ecosystems have to do with OSGi?
• How we develop or migrate more easily enterprise applications or smart home applications?
• Whether OSGi is just for gurus?
• What you want to know about versioning, subsystems, or class-loading in OSGi based systems?
• How do you make your code OSGi friendly?
• And why business solutions from Deutsche Telekom, Cisco, and Telecom Italia are heavily based on OSGi technology?

 These and more questions will be answered at the OSGi Community Event 2012 - the program reflects the broad use of OSGi technology in diverse markets and product solutions and also includes

• Suggestions for future specification work,
• OSGi in C and C++,
• And developer benefits to use OSGi/bnd tools in their workflow.

 In order to further leverage the benefits for all attendees and foster the exchange of information and activities in the constantly growing ecosystem, the OSGi Community Event 2012 is co-located with EclipseCon Europe. Mingle and benefit from the cool program … and during the evenings chill and digest the huge information flow while listening to a live band and having loads of fun, including a competition involving an Aibotix drone which also will be presented in Jörg Lamprecht’s key note.

So there’s a terrific program, a lot of opportunities to learn, share, and mingle and, certainly, also to party together.  To top all past conferences, we wait for you and your colleagues to participate and get involved. Discounts? First of all, enter the coupon code 'OSGi'; then, benefit from the early bird (until September 30th), student, press, academics or group discounts.

Now it’s your turn to register – welcome (back) to exciting times!

Susan Schwarze
OSGi Alliance VP Marketing

OSGi Picking Up The Pieces

Jigsaw – the prototype project that was widely expected to become the Java™ SE 8 Module System – might now be deferred to at least Java 9. Given this uncertainty, the OSGi Alliance felt it was appropriate to state our position with respect to Java platform modularity.

Modular systems reduce maintenance and development time and so cost. For these reasons, the OSGi Alliance has dedicated more than a dozen years to the pursuit of modularity, creating the dynamic module system for Java. Now in 2012, OSGi is in daily use creating highly maintainable, extensible, and agile business applications and solutions. Application and systems developers already benefit from the mature OSGi dynamic module system for Java, proven with its adoption worldwide in Fortune Global 100 company products and services and in diverse markets including enterprise, mobile, home, telematics and consumer. The OSGi Alliance and its members continue to simplify the use of OSGi and invite the wider Java community to support this work, including documentation efforts.

Clearly, a modularized Java platform would complete this story: reducing both bloat and memory footprint, improving startup times, better accommodating embedded environments, and future-proofing Java with removable components would be highly beneficial for Java developers, architects and users.

Designing a module system takes time and experience and so the OSGi Alliance supports Oracle’s consideration not to ship Java SE 8 with Jigsaw. Especially as an incomplete modularity design would hurt the Java community. Yet, we should not delay the work on the Java Module System JSR.

The solution

OSGi technology is based on open industry specifications and more than a decade of experience. The OSGi Alliance recommends that the Java community use OSGi as the cornerstone technology to modularize the Java platform; OSGi already providing not only the necessary technology foundation to successfully achieve modularization of Java SE, but also a growing ecosystem of developers and deployers of OSGi technology. The Module System JSR should be based on OSGi concepts, and enable similar maintenance, extensibility, and agility benefits for the Java platform, creating a single, coherent modularization approach from the Java platform up through the application.

How do we move forwards?

Today the only module framework that exists for Java is that defined by the OSGi Alliance standards. Based on these foundations, the Alliance is willing to work with our existing ecosystem of experienced partners, the JCP and the wider Java community to collectively design the best Java Module System to secure the future of the Java platform. Collectively, we can accelerate the JCP process and related projects like Penrose; and most importantly deliver the module system design that the Java community deserves. The Java Module System JSR needs to be started right away to begin this challenging work.

Richard Nicolson
OSGi Alliance President

New RFPs available for feedback

Over the past while we have started making RFPs available at OSGi for public comments before they are finalized and voted on. This has worked really well for the OSGi Cloud RFP and the OSGi/CDI integration RFP.

Four new RFPs have been made available as part of this process. The RFPs describe uses cases and requirements which will ultimately feed into RFC work that will be the basis of future OSGi specifications.

RFP 143 OSGi Connect

The people at PojoSR have done some great work in showing how you can use OSGi Services in cases where you may not want to take on OSGi modularity (yet). RFP 143 captures requirements for creating a specification around this. The RFP can be found here: RFP 143.

RFP 150 HTTP Service Updates

The OSGi HTTP Service is widely used and it provides a very nice programming model for sevlets in an OSGi environment. However the specification is in need for an update to modernize it in relation to the Servlet spec itself. Additionally, the whiteboard pattern is introduced for servlet. You can find the RFP here: RFP 150.

RFP 151 Declarative Service Updates

A variety of updates are proposed to the Declarative Services specification. They can be found in RFP 151.

RFP 152 EJB Integration

EJB integration with OSGi has been done at Apache Aries and Glassfish. Other appservers such as JBoss and others also provide some form of interaction between EJBs and OSGi. This RFP aims a writing a specification for this integration to make OSGi-enabled EJBs portable. You can find the RFP here: RFP 152.

If you have thoughts or opinions about the above topic, have a read of the RFPs and put your comments on the associated bugs.

Core Release 5 and Enterprise Release 5 specifications

The OSGi Alliance has just published the recently approved Core Release 5 and Enterprise Release 5 specifications and made them available for download.

Some highlights from the new specifications include:

OSGi Core Release 5

• New Resource API for modeling generic capabilities and requirements.
• New Version Range class.

OSGi Enterprise Release 5

• New Repository Service Specification provides declarative access to artifact repositories based on the generic capabilities and requirements model. Where traditional repositories have typically provided artifacts based on their name, version and group, the OSGi Repository can provide artifacts based on capabilities, such as packages exported, services provided, extender functionality provided or custom-defined capabilities.
• New Resolver Service Specification. Based on the generic capabilities and requirements model, a management agent can use the Resolver service to compute the set of necessary resources needed to satisfy the given set of requirements. The Resolver is designed to work with the Repository Service, if available.
• New Subsystems Service Specification provides the ability to group multiple bundles into a single manageable entity, allows for complete isolation as well as various sharing models of code, services, and resources through a management agent. The Subsystem Service Specification defines an archive format to package multiple bundles, the Enterprise Subsystem Archive (.esa).
• New Service Loader Mediator Specification addresses common problems of bundles that rely on the java.util.ServiceLoader API to load custom Service Provider Implementations. It describes how to use the service registry for lookup of Service Providers as well as a solution for existing code to continue functioning using Service Loader API in a OSGi environment.
• New Common Namespaces Specification for use with the generic OSGi capabilities and requirements model.
• The Extender Namespace allows a bundle that requires an extender, such as Declarative Services or Blueprint, to express this dependency.
• The Contract Namespace provides a shorthand for many Import-­‐Package statements for technologies which span multiple packages.
• The Service Namespace allows a bundle to express that it provides or consumes a certain service.
• Updated JMX Management Model Specification.
• Object names now contain framework name and UUID, which allow multiple frameworks to be represented side-­by-­side.
• Updated the JMX API to reflect the latest Core API, specifically the bundle wiring API.
• Many improvements as requested by users, often focused on limiting the amount of data communicated via JMX APIs.
• Updated Configuration Admin Specification.
• Added targeted PIDs, which can be useful when configuring multiple versions of the same bundle through Configuration Admin.
• Added persistent change count to make it easier to detect changes.
• Added Synchronous Configuration Listener.

The specification PDFs, companion code jars and javadoc are now all available for download from the OSGi website.

OSGi/CDI integration RFP available for public comments

One of the new topics being discussed in the OSGi Enterprise Expert Group is integration with CDI (JSR 299). In short - the idea is that CDI beans in OSGi can receive their injections from the OSGi Service Registry. Additionally, CDI beans themselves can be registered in the OSGi Service Registry so that other bundles running in the OSGi framework can use them as OSGi Services.

Obviously, other component models already exist as OSGi specifications: we have Declarative Services and Blueprint. The CDI/OSGi integration will bring the CDI programming model into OSGi, and especially developers from the JavaEE world could be interested in continuing to use CDI inside OSGi. In my opinion it's not one size fits all. Developers have their own preferences and having a choice of programming models is good.
Also, the nice thing about the OSGi Service Registry-based approach is that all these component models work together, so I can write a Blueprint component and consume that as an OSGi Service in my CDI bean. And any other combination is also possible.

The OSGi/CDI discussion takes place in RFP 146. The RFP is a requirements document, once we agree on the requirements the details of the technical design will be discussed in an RFC.
As we did in the past with the Cloud Computing RFP 133, we're inviting everyone to comment or refine the requirements.
You can find the OSGi/CDI RFP here: OSGi RFP 146.

Repository Complex Requirements
Besides the OSGi/CDI RFP, another RFP has also been published for comments. This is RFP 148 Complex Repository Requirements. This is a much more narrow-focused RFP that aims at extending the capabilities of the Repository Service which is part of the upcoming R5 Enterprise Release (already available as EA Draft). Currently the Repository query API only accepts requirements within a single namespace. RFP 148 aims at extending this to allow requirements that cross namespaces. An example of this would be: I need a bundle that provides the package javax.servlet and has the Apache License.
Why wasn't this part of the Repository spec in the first place? Very simple, we ran out of time. So rather than rushing this feature in or delaying the Repository spec, we decided to work on it after the initial Repository Release. That's why we're looking at this RFP now, you can find it here: OSGi RFP 148.