An evening of OSGi with BGJUG on April 17 Sofia, Bulgaria

The BGJUG and Software AG are kindly hosting an Evening of OSGi on Tuesday April 17 from 7pm.

The OSGi Alliance is in Sofia conducting its Expert Group face to face meetings and Board meeting so this evening event will provide an excellent opportunity to meet with the local Java community while we are in town.

There are two talks lined up from the OSGi Alliance:

• the first is an 'Introduction to OSGi' by BJ Hargrave (OSGi Alliance CTO) and 
• the second is a look at 'How OSGi Alliance specifications have influenced the IoT market' by Pavlin Dobrev & Kai Hackbath (Bosch). 

In addition Todor Boev from Software AG will be presenting 'OSGi and JPMS in practice' which will discuss Software AG's experiences with OSGi and Jigsaw/JPMS now that Java 9 is released.

The event is being held at Sofia Tech Park / Incubator building, Tsarigradsko shoes 111B, 1784 Sofia [MAP].

Please be sure to register in advance to secure your place.

Thanks to BGJUG and Software AG for their assistance in arranging this event and of course to the speakers for their support.

We hope you can join us.

Letter to our OSGi User Community RE: the Java Platform Module System (JPMS)

Letter to the OSGi User Community:

With the JCP Executive Committee’s acceptance of JSR 376, the Java Platform Module System (JPMS) will be included in the Java SE 9 release. The OSGi Alliance has recently completed an analysis of JPMS and what it means for our user community.

We recognize that many of you have invested in OSGi technology over a number of years and have business-critical systems that rely on OSGi, so you may question if and how Java SE 9 may impact you. Please be assured that OSGi will continue to operate with its full capabilities on top of the new Java SE 9 platform.

However, the modularity capabilities in OSGi and JPMS are not the same. Our modularity experience, earned through the evolution of OSGi, has proven there are specific requirements in modularizing an application that is assembled with code from multiple sources, which have independent release cycles. Given these requirements, JPMS is not suitable for most real-world applications and we therefore caution against the use of JPMS for the application layer.

As you know, the modularization of an application, where code and dependencies are pulled from many independently created sources, presents a different set of challenges than those faced in the modularization of a defined and closely managed platform. This difference is especially true when the entire code base is managed by a single entity and released all at once, like the Java platform.

For more than 15 years, OSGi has proven successful in modularizing user applications by using dynamic resolution and semantic versioning, as well as supporting isolation, multiple class loaders and dependency injection. With its goal of modularizing the platform, JPMS has been able to rely upon static dependency resolution and ignore versioning, deferring responsibility for versioning to others.

Clearly, both OSGi and JPMS will co-exist and effectively operate in this application/platform demarcated environment. The modularization of the Java platform with Java SE 9 is a significant step forward for Java as a whole, and OSGi technology’s role in application-level modularization is as important today as it has been for previous releases of Java.

If you have any technical questions, please post them to osgi-dev@mail.osgi.org or, if you prefer an off-list inquiry, email modularity@osgi.org.

Sincerely,

Dan Bandera

President

OSGi Alliance

Java is registered trademark of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. OSGi is a trademark or a registered trademark of the OSGi Alliance in the United States, other countries, or both.

OSGi and JSR 376 Java Platform Module System (JPMS)

The OSGi Alliance is aware that there are a number of conversations taking place about the Public Review draft of JSR 376 Java Platform Module System (JPMS). This is planned to be a major feature of Java 9 and is under ballot to complete Public Review. The OSGi Alliance will analyze JPMS and may comment on our findings in the future.

In the meantime our Expert Groups are busy working on the OSGi Release 7 which is planned for October this year. You can find the RFPs and RFCs for the new Release 7 features at https://github.com/osgi/design and draft specifications at https://www.osgi.org/developer/specifications/drafts/.

BJ Hargrave
OSGi Alliance CTO

InfoQ: A comparison of OSGi and the Java 9 Java Platform Module System

In Java 9, OSGi and the Future of Modularity, Neil Bartlett and Kai Hackbarth provide part 1 of an excellent comparison of OSGi modularity and the current state of Java 9's Java Platform Module System (JPMS) modularity.

One of the most common complaints about OSGi is that it can increase complexity for a developer. There is a grain of truth here, but people who make this complaint are mistaking the medicine for the disease.
Modularity is not a magic dust that can be sprinkled onto an application just before release. It is a discipline that must be followed throughout all phases of design and development. Developers who adopt OSGi early and apply modular thinking before writing a line of code realise enormous gains[...]

Project Jigsaw started with a goal of being simple, but the JPMS specification has increased enormously in complexity: the interplay of modules with class loaders; hierarchical layers and configurations; re-exporting requirements; weak modules; static requirements; qualified exports; dynamic exports; inherited readability across layers; multi-module JARs; automatic modules; unnamed modules… all these features have been added as the need for them became clear. A similar process happened in OSGi, just with a 16-year head start.

The article is well written and provides a clear understanding of the differences between OSGi and JPMS as it stands today. Looking forward to part 2.

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