OSGi—the basics - Enterprise OSGi in Action - page 340

Although object orientation provided good modularity, it didn't provide enough
modularity, particularly for embedded systems. A nonprofit industry consortium
known as the OSG i Alliance set out to design a system that enabled greater modularity
in Java. In addition to Sun, IBM , and Oracle, its original members were, for the most
part, mobile phone manufacturers like Motorola and Ericsson, and networking com-
panies like Lucent and Nortel. There were also energy companies involved, such as
Electricité de France and the late Enron Communications. OSG i is used in a surprising
range of systems, from cars and locomotives to set-top boxes and application servers.
Because of the small physical size of an embedded device, the Java classpath for
each software component had to be well-defined and compact. Devices might be phys-
ically appearing and disappearing off the network at any time as users plugged them
in, so the coupling model had to be loose and fully dynamic. Modern application serv-
ers have a lot of disk space accessible to them, but they still have classpath problems.
Because they're trying to do so much, their classpath will bloat uncontrollably unless
there's some sort of dependency-management scheme in place. Similarly, the enor-
mous span of the system means that the abilities to keep couplings loose and dynami-
cally register and unregister components are essential.
OSG i came to the attention of the mainstream Java community in 2003, when
Eclipse made the technical shift to OSG i. Eclipse was already using a home-rolled
modularity system to power its plug-in architecture, so it made a lot of sense to switch
to a more standardized solution. After Eclipse made the leap, application server ven-
dors then started to base their servers on OSG i. IBM WebSphere, Oracle WebLogic,
Apache Geronimo, GlassFish, and JB oss are now all built out of OSG i bundles. OSG i is
firmly in place in middleware implementations, and most middleware vendors are
members of the OSG i Alliance.

A.2 Versions

We discuss OSG i versioning in sections 1.2.1 and 5.1.1. But versioning is important
enough that it's worth revisiting to re-emphasize the basics and cover some of the sub-
tler points before we continue with our OSG i refresher.
Bundles, exported packages, and imported packages may all have versions. Bun-
dles and package exports specify an exact version, but package imports use a ver-
sion range. Although versions are optional, being disciplined about specifying
versions is a good practice and can avert a range of compatibility problems as devel-
opment progresses.
Version ranges are defined using the standard mathematical convention for inter-
vals. Square brackets represent an inclusive range, and round parentheses an exclusive
range.

A.2.1 The semantic versioning scheme

Versioning is a way of communicating about what's changing (or not changing) in
software, and so the language used must be shared. Consumers of a class must be able