What classloaders are created by the module system?

Overview

This FAQ item should be a companion to the main classpath documentation. Please refer to the original document for additional details.

Classloaders in the NetBeans platform

There are basically three main classloader types used in the platform. Most of the code should be loaded by the Modules classloader. Only in justified special cases the System classloader can be used - e.g. when you need access to resources from all the modules. And finally the resources directly on the classpath from the launch script are loaded by the original classloader (the term boot classloader might be a bit confusing because of the bootstrap classloader used by the JVM).

Most of the classloaders in the NetBeans platform are multi-parented classloaders. This means that the classloader can have zero or more parents. When looking for a resource the classloader uses this algorithm (implemented in class org.netbeans.ProxyClassLoader):

Modules Classloader

Every module registered by the module system creates one instance of the Module classloader. The classloader loads resources primarily from the module's jar file. This classloader is able to load from more jar files (besides having more classloaders as parents). The original (application) classloader is implicitly one of the parents of each module's classloder - always at the first position.

• locale extension - jar file placed in subfolder locale relative to the original module jar file position named by appending a locale suffix to the original name - is again loaded by this classloader
• patch - jar file placed in directory patches relative to the original jar file position is also loaded by this classloader

The implementation class is org.netbeans.StandardModule$OneModuleClassLoader. The ability to use more jar files is implemented in its superclass org.netbeans.JarClassLoader.

System Classloader

The system classloader is regular multiparented classloader that has as its parents all module's classloaders. It is accessible via call to the global lookup (ClassLoader)Lookup.getDefault().lookup(ClassLoader.class); or by using the fact that it is the context classloader on most of the threads: Thread.currentThread().getContextClassLoader();.

Original (application, JNLP) Classloader

This classloader is set up by the launching script. It is usually able to load classes from the original CLASSPATH plus clontents of the folder lib (with usual subfolder lib/ext). If a jar is loaded by this loader and it does not have proper manifest information required by the NetBeans module system the contained resources "bypass" the NetBeans module system. Also such resources are always found first if by accident the same resource is contained here and in a module jar (the module supplied resource is ignored in such case). It is generally discouraced to use this classloader for loading anything in the platform but it is sometimes needed e.g. for the Look And Feel classes (that has to be loaded very early during the startup sequence).

Example

example.gif

Let's have a very simple module a:

Manifest-Version: 1.0
OpenIDE-Module: org.netbeans.modules.a

and module b depending on a:

Manifest-Version: 1.0
OpenIDE-Module: org.netbeans.modules.b
OpenIDE-Module-Module-Dependencies: org.netbeans.modules.a
Class-Path: ext/library-a-1.0.jar ext/library-b-1.1.jar

Module b also declares a dependency on 2 external libraries - they will be loaded by the very same classloader as b.