Outlines what an OSGI framework is

Now more and more Java developers are talking about OSGi for a reason. When I went to school a few years ago, I had a lot of eclipse plug-in development, and I felt the flexibility and power of the Eclipse plug-in system, and the system and OSGi were same strain and feather. Recently planned to re-study OSGi, while learning to write an OSGi Quest series as a summary, and share with you, please give more comments and suggestions.

In this article, I want to answer a basic question: what is OSGi? In fact, if you want to answer this question very well, it may be helpful to understand what caused the production and development of OSGi in the first place.

Believe that every Java programmer knows what classpath is. The Java ClassLoader (Classloader) is a hierarchical structure, as shown in the Boot class loader (Bootstrap class Loader), the extension ClassLoader (Extension class Loader), the System class loader (systems Class Loader) and a user-defined ClassLoader (user-defined class Loader). The boot ClassLoader is responsible for loading the classes in the Rt.jar in the JVM, the extension ClassLoader is responsible for loading the classes in the jar file in the extended directory, the system ClassLoader searches the class loader on the Classpath, and the user-defined ClassLoader loads the class from the user-specified path, 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, one layer at a time, and when the required class cannot be found, it loads itself.

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 ClassLoader finds a version, the next version is no longer searched for loading ; 2) Unable to determine dependencies between jars: the existing jar standard lacks the definition support for dependencies between jar files, so only when the required classes are not found at run time Will not play java.lang.ClassNotFoundException, but this usually does not effectively help developers to solve the problem; 3) information hiding: If a jar is on the classpath and is loaded, then all public classes in that jar Class) is loaded, and there is no way to prevent certain classes from being hidden from being loaded. Although the class loading mechanism has been improved in the Java EE, it can be supported as a war or ear application for the unit to load, but these problems are not well solved, and the thermal deployment effect is disturbing.

OSGi was born to overcome these problems without limiting them, and for Java developers it was a great meal. OSGi is a dynamic Java module system that defines how a module is defined and how the modules interact with each other. Each OSGi Java module is referred to as a bundle. Each bundle has its own classpath, which can specify exactly which Java packages and classes can be exported, which classes and packages of other bundles need to be imported, and thus indicate dependencies between bundles. In addition, bundles can be installed, updated, uninstalled, and not affected by the entire application at run time. In this way, the layered class loading mechanism becomes a mesh class loading mechanism. Before the application is launched, OSGi can detect whether all dependencies are met and, when not satisfied, accurately report which dependencies are not met.

of course, OSGi is more than that. I'll systematically describe what OSGi is and what's inside of it in a subsequent series of articles.

Outlines what an OSGI framework is