Berlin Brandenburg JUG OSGi Meetup - Tues 19 Feb, 2019 - 18.30hrs

Belated New Year Wishes to all in the OSGi Community.  We hope you had a good festive break and no doubt are settled in for the year ahead.

We are pleased to announce the first OSGi event of 2019.  Join us on Tues 19 Feb in Berlin, Germany. The OSGi Alliance is holding its Expert Group meetings in town that week and we are pleased to have secured some interesting talks covering OSGi and Java 9 and beyond, Realtime OSGi and the edge, and also a look at a number of popular patterns to use with OSGi.

Thanks to the Berlin Brandenburg JUG for their support in arranging this event, also to the OSGi Users' Forum Germany and to Bosch for hosting us and providing refreshments.


This Berlin Brandenburg JUG event is being supported by the OSGi Users’ Forum Germany and Bosch.  The meeting will be held at the Bosch IoT Campus in Berlin and doors open at 18.30 for a beer and some networking in advance of the 19.00hrs start of the talks. 

Registration is essential so we know numbers for the drinks and pizza kindly provided by our hosts Bosch.

18.30hrs - Doors open for beer and networking
19.00hrs - Welcome from Berlin Brandenburg JUG organizers & Bosch
19.10hrs - OSGi and Java 9+
19.40hrs - Fit for the Edge: Making OSGi Robuster and Realtime Capable
20.10hrs - Popular patterns revisited on OSGi
20.40hrs - Pizza and networking

Further details on the talks and presenters are provided below.

Location: Bosch IoT Campus, Ullsteinstraße 128, 12109 Berlin, Germany [MAP]

Registration:  https://www.meetup.com/de-DE/jug-bb/events/258444067/

OSGi and Java 9+ (BJ Hargrave, IBM) 
Abstract: 
Java 9 introduced the Java Platform Module System (JPMS) as a way to modularize the Java platform and it can be also be used by developers to modularize their own applications, although JPMS lack a number of important features for software running on the Java platform.

As people look to support the latest versions of the Java platform, changes introduced in Java 9 related to JPMS led to the needs for some features in the OSGi Core specification. OSGi framework implementations like Eclipse Equinox and Apache Felix and tools like Bnd were updated to support these new features.

Bio: 
BJ Hargrave is CTO of the OSGi Alliance and chair of the OSGi Core Platform Expert Group.  His day job is as Senior Technical Staff Member in the IBM Digital Business Group. BJ has led the development of OSGi technology since its inception and is a committer on the Eclipse Equinox project and the Bndtools project.

Fit for the Edge: Making OSGi Robuster and Realtime Capable (Dr James Hunt, aicas)
Abstract: 
OSGi brings many benefits, but it lacks two important features for Industry 4.0: strong bundle isolation and the ability to provide realtime guarantees.  The Realtime Specification for Java 2.0 provides
the basis for filling this gap.  It provides both APIs and JVM semantic refinements for realtime programming and resource management.  Marrying these features to OSGi will make OSGi the leading platform for edge computing.

Bio:
Dr. James J. Hunt is CEO and cofounder of aicas GmbH, the leading provider of realtime Java technology for embedded system.  Educated at Yale, Boston University, and the University of Karlsruhe, he has worked in diverse projects such as restructurable wafer scale integrated circuits (RVLSI), parallel Lisp, software standards, and realtime Java. He is the specification lead for the Real-Time Specification for Java (JSR-282). He was also European Cochair for the subgroup on object-oriented technology of the SC-205 Plenary for updating software safety standard for avionics, resulting in the Object Oriented and
Related Technology Supplement now published as DO-332 and ED-217.  He joined the OSGi Alliance to bring realtime to OSGi.

Popular patterns revisited on OSGi (Christian Schneider, Adobe)

Abstract:

We will look at common cloud and design patterns and see how the special properties of the OSGi environment allow us to rethink these patterns. The talk shows some well-known patterns like the service registry and the whiteboard but also some unique patterns like out of band circuit breaker or graceful degregation. The patterns are shown with some examples using declarative services(DS). So some basic OSGi and DS knowledge is of advantage but not required.

For OSGi beginners, the well established OSGi patterns will help getting started the right way. Experienced OSGi developers will find some new patterns to think about. Cloud or enterprise developers will get a new approach to some patterns they are used to which hopefully inspires them to take another look at the current state of OSGi.

Bio:

Christian is a computer scientist working at Adobe on the Adobe Experience Manager Platform team. On the open source side he is involved with quite a few Apache open source projects like Felix, Karaf, CXF, Camel. Christian is interested in clean code, software architecture and modular software design.

We hope you can join us in Berlin next month.  If you have any questions please contact us by email.

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.

OSGi R7 Highlights: Java 9 Support

With the Java 9 release, the Java Platform Module System (JPMS) is a major feature that impacts many areas of the Java Platform.  The JPMS is used to modularize the class libraries provided by the Java Platform.  In addition, it has been proposed that the JPMS can be used by developers to modularize their own applications, although the OSGi Alliance cautions against its use here.

Meanwhile the OSGi Core specification has provided a stable platform for developing modular Java applications for well over 17 years.  The OSGi Core R7 specification continues this tradition by providing updates to the OSGi Core specification which are fully compatible with previous versions of the OSGi Core specification.  OSGi Core R7 Framework implementations will be able to run on top of Java 9 without requiring any changes to existing OSGi application bundles (assuming no internal packages from the Java platform are being used).

The OSGi Core R7 specification has a couple of new features that build upon some features new to Java 9.  This includes support for multi-release JARs and runtime discovery of packages provided by the JPMS modules loaded by the platform.  First I will tell you about the multi-release JAR support.

Multi-Release JAR Support

Java 9 introduces a new type of JAR called a multi-release JAR.  A multi-release JAR file allows for a single JAR to support multiple major versions of the Java platform. For example, a multi-release JAR file can depend on both the Java 8 and Java 9 major platform releases, where some class depend on APIs in Java 8 and other class depend on APIs in Java 9.

The purpose of multi-release JARs is to support alternative implementation of select classes to deal with changes in the visible APIs of the Java platform.  That is, it is not meant as a means to supply new function or new API on different Java platform versions. As a best practice new APIs should be released in an updated version of an existing bundle or released as part of a new bundle.

The OSGi Core R7 specification adds support for multi-release JAR files. An OSGi bundle file can be a multi-release JAR by adding the following manifest header to the bundle manifest:

 Multi-Release: true

Any JAR included on the bundle class path can also be independently declared as a multi-release JAR by including the same manifest header:

  Multi-Release: true

in its own JAR manifest. For example, an OSGi bundle can include third-party multi-release JARs on its own bundle classpath. In this case the third-party multi-release JARs will be loaded as multi-release JARs by the OSGi Framework even if the bundle JAR itself is not a multi-release JAR.

When a JAR on the bundle class path is a multi-release JAR, then the Framework must search the JAR's versioned directories when attempting to locate a class or resource in the JAR. For more information on how classes and resources are loaded from multi-release JARs see the multi-release JAR documentation.

Different implementations of a Java class for different versions of the Java platform can affect the requirements of the bundle.  For example, what packages need to be imported from the running Java platform. The R7 Framework supports supplemental manifest files that can be used to specify alternative values for the Import-Package and Require-Capability manifest headers for different versions of the Java platform.

When a bundle file is a multi-release JAR, then the Framework must also look for a supplemental manifest file, OSGI-INF/MANIFEST.MF, in the versioned directories. For example:

  META-INF/versions/9/OSGI-INF/MANIFEST.MF

The Framework finds the highest versioned manifest available in the multi-release JAR which can be applied to the running Java platform and uses the Import-Package and Require-Capability manifest headers as replacements for the values specified in the bundle's manifest.

The purpose of the supplemental manifest is to specify requirements on capabilities provided by different versions of the Java platform which are needed by the implementation classes for that Java platform version. As a best practice, the supplemental manifests should not contain additional requirements on capabilities which are not supplied by the Java platform for the Java version associated with the supplemental manifest.

For more information about multi-release JAR support you can refer to the following sections of the OSGi Core R7 specification:

1. Bundle File Multi-release JAR
2. Bundle class path Multi-release Container

Runtime Discovery of Java Platform Packages

Now that the Java platform is modularized in Java 9, the runtime can be configured to load only the modules which are required by the application.  This allows for a smaller custom runtime that is tailored to the needs of a specific application.  The set of java.* packages provide by the running Java platform is no longer constant for a specific version of the Java platform.

Bundles typically depend on different packages by using requirements specified with the Import-Package header, but as of the OSGi Core R4 specification, bundles have been prohibited from using Import-Package to specify requirements on java.* packages.  Instead bundles have used the osgi.ee namespace (or the deprecated Bundle-RequiredExecutionEnvironment header) to specify a dependency on specific versions of the Java platform. It has been assumed that the set of java.* packages available for a specific version of the Java platform is constant and therefore there is no need to specify additional requirements on specific java.* packages.

With Java 9 this is no longer a valid assumption.  With OSGi Core R7, the osgi.ee namespace should only be used to specify the minimal level of the Java platform required by the Java class bytecode level included in the bundle.  Dependencies on specific java.* packages should to be specified using the Import-Package header.

The OSGi Core R7 specification now allows bundles to use the Import-Package header to import java.* packages.  The OSGi Framework implementation is required to discover the all available java.* packages in the running Java platform and automatically provide the java.* package as a separate system packages (see the system packages configuration property).  The system bundle is the only bundle that is allowed to provide java.* packages. It is an error for normal bundles to attempt to export java.* packages using the Export-Package header.

When importing java.* packages only the package name should be specified, no other matching attributes are needed.  For example:

  Import-Package: java.sql

Note that bundle class loaders in R7 continue to have full visibility to all available java.* packages available in the running Java platform.  The class and resource loads for the java.* packages will continue to be boot delegated by the framework implementation even when the bundle does not specify any Import-Package header. The java.* package requirements are only necessary to prevent a bundle from resolving if the necessary java.* packages are not available at runtime.  For example, if a bundle must only resolve if the java.sql module is loaded.

For more information about java* package support you can refer to the following sections of the OSGi Core R7 specification:

1. Execution Environment
2. Parent Delegation 

Bundles Supporting R6 and R7 Frameworks

The OSGi Core R6 specification prohibits bundles from importing java.* packages and will throw a BundleException if such a bundle is attempted to be installed. Bundles that must work on OSGi R6 and earlier Frameworks but also want to run on R7 Frameworks have two options:

1. Do not import the java.* packages.  The bundle will continue to work on an R7 framework because java.* packages are still boot delegated by the bundle class loaders. This implies the bundle may resolve when running on Java 9 even when all the java.* packages required by the bundle are not available.
2. Package the bundle as a multi-release JAR to allow alternative values for Import-Package to be specified.

A bundle that must still be able to be installed on an OSGi R6 or earlier Framework must not specify java.* packages in their main bundle manifest Import-Package header. A supplemental manifest must also be included to be able to specify java.* package imports.

This supplemental manifest must contain the original Import-Package header from the main bundle manifest as well as any java.* package required by the bundle. When running on an OSGi R6 Framework, this supplemental manifest will be ignored and therefore the bundle will install successfully as the bundle did not specify an import for the java.* packages in the main manifest.

If a bundle will always require OSGi R7 or greater Framework, there is no need to use multi-release JARs for this purpose even when the bundle must support Java 8 or earlier. This is because OSGi R7 frameworks must provide the java.* package capabilities on all Java platform versions the framework implementation supports. As long as the java.* package is available on the running Java platform, the bundle with an import for the java.* package must resolve.

I advise using option 1 here because it is by far the most simple approach.  If you really have a strong need to use this new R7 feature then I recommend you do not try to produce a single bundle version that supports both R6 and R7 Frameworks.  Instead simply release a new version of your bundle that only supports OSGi R7 or greater Frameworks.

In Summary

The OSGi Core R7 release continues the tradition by providing a stable modular platform with updates to the OSGi Core specification which are fully compatible with previous versions of the OSGi Core specification.  OSGi bundle developers can continue to develop advanced modular applications and run their applications on Java 9 without having to commit to migrating to the green initial release of JPMS.

The OSGi Core R7 specification does add new functionality in support of new features available in Java 9, such as the support for multi-release JARs and importing of java.* packages.  The OSGi specifications will continue to evolve in order to provide the necessary tools for developing advanced modular applications.

OSGi R7 Highlights: Proposed Final Draft Now Available

I am pleased to announce that the OSGi Alliance has published the Proposed Final Drafts of the OSGi Core R7 and Compendium R7 specifications. We expect that the final versions of these specifications will be published in April 2018 after OSGi Alliance member approval.

The R7 release builds upon the long history of the OSGi Alliance’s leadership in Java modularity and reflects a significant amount of effort from the technical members of the OSGi Alliance expert groups over the last 2 years. Thanks go to all of the members who have contributed to this release.

R7 represents many significant new features and capabilities and provides an open standards-based approach for a number of modern valuable and simple-to-use technologies important to Java developers.

This blog post is the start of a series of blog posts from the technical experts at the OSGi Alliance to share some of the key highlights of R7. The blog posts in this series will come out over the coming weeks and cover the following topics:

• Java 9 Support – Multi-release JAR support and runtime discovery of the packages provided by the JPMS modules loaded by the platform.
• Declarative Services – Constructor injection and component property types.
• JAX-RS – A whiteboard model for building JAX-RS microservices.
• Converter – A package for object type conversion.
• Cluster Information – Support for using OSGi frameworks in clustered environments.
• Transaction Control – An OSGi model for transaction life cycle management.
• Http Whiteboard – Updates to the Http Whiteboard model.
• Push Streams and Promises – The Promises packages is updated with new methods and an improved implementation and the new Push Streams package provides a stream programming model for asynchronously arriving events.
• Configurator and Configuration Admin – Configuration Admin is updated to support the new Configurator specification for delivering configuration data in bundles.
• LogService – A new logging API is added which supports logging levels and dynamic logging administration and a new Push Stream-based means of receiving log entries is also added.
• Bundle Annotations – Annotations that allow the developer to inform tooling on how to build bundles.
• CDI – Context and Dependency Injection support for OSGi developers.

Stay tuned and I hope you find the technical information in the blog post series useful to you as developers!

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.