OSGi Learning Path (1)-Overview What is the OSGi framework _osgi

Now more and more Java developers are talking about OSGi in a way that makes sense. When I went to school a few years ago, I did a lot of Eclipse plug-in development, and then I personally felt that the Eclipse plug-in system is flexible and powerful, and the system and OSGi are also feather. Recently intend to re-examine the system of OSGi, while learning to write an OSGi exploration series as a summary, and you share, please give more comments and suggestions.

In this article, I want to answer a basic question first: what is OSGi. In fact, if you want to answer this question well, it may be helpful to understand first what causes OSGi to occur and develop.

Believe that every Java programmer knows what classpath is. The Java ClassLoader (Classloader) is a hierarchical structure, as shown in the following illustration, divided into a boot class loader (Bootstrap class Loader), an extended ClassLoader (Extension class Loader), and a system class loader Class Loader) and the user-defined class loader (user-defined class Loader). The Boot class loader is responsible for loading the classes inside the Rt.jar in the JVM, the Extended class loader is responsible for loading classes in the jar file in the extended directory, and the System class loader searches the classpath for the ClassLoader, and the user-defined ClassLoader loads the class from the path specified by the user, such as a network URI. In this kind of loading system, a class loader always first goes to the upper class loader to load the class, layer by layer, and then load itself when the required class cannot be found.

In this kind of loading mechanism, there are several problems: 1 class version conflict: When different versions of the same class exist on the Classpath, if the class loader finds a version, it no longer searches for the next version to load 2 cannot determine dependencies between jars: there is a lack of definition support for dependencies between jar files in existing jar standards, so only if the required class cannot be found at run time, Java.lang.ClassNotFoundException, but this is usually not an effective way to help developers solve problems; 3 Information hiding: If a jar is on the classpath and is loaded, then all the common classes in that jar (public Class) is loaded and cannot be prevented from being loaded because some classes are hidden. Although the class loading mechanism has been improved in Java EE, it is possible to support the use of war or ear applications as a unit for loading, but these problems are not well addressed, and the thermal deployment effect is disturbing.

OSGi is designed to overcome these problems without limiting them, and it is a great meal for Java developers. OSGi is a dynamic Java Module (module) system that sets out how to define a module and how these modules interact with each other. The Java module for each OSGi is called a bundle. Each bundle has its own classpath, which can specify exactly which Java packages and classes can be exported, what other bundle classes and packages need to be imported, and thus indicate the dependencies between bundle. In addition bundle can be installed, updated, unloaded at run time and do not affect the entire application. In this way, the layered class loading mechanism becomes a network class loading mechanism. Before the application starts, OSGi detects whether all dependencies are satisfied and, when not satisfied, accurately reports which dependencies are not met.

Of course, OSGi is more than that. I will introduce in the next series of articles what is OSGi and its internal secrets.