How Classes are Found

To approximate the Java dynamic class loading and resolution behavior found in a standard Java platform, the Ja.NET SE infrastructure builds and maintains an association between the loaded assemblies in the process and the Java class loaders running in the system. At any point in time, a given Java class loader can have zero or more assemblies associated with it, and a single assembly can be associated with one and only one Java class loader.  In this section, we describe how Ja.NET SE uses this infrastructure to dynamically link to classes at runtime.

When the Ja.NET SE runtime is first initialized, it creates a class loader hierarchy similar to what you find in a standard Java platform.  It then initializes the assembly associations for each of the created loaders.  The initial loader hierarchy contains the SE bootstrap class loader, followed by the extensions class loader as its only sibling.  Then the system or application class loader as a sibling to the extensions loader.  To get a full understanding of how assembly associations are initially created and managed, read the section, How Assemblies are Found.

The default implementation of the class resolution algorithm in SE is the same as that found in a standard Java platform with one small difference; It uses the assembly associations when searching for classes.  When a loader is asked to load a class, it searches for the class using the following algorithm:

• First the loader checks to see if the class has already been loaded. It does this by searching through all of the assemblies that are currently associated with the class loader looking for the class. If it is found, it returns it. Otherwise, the search continues to the next step.
• If the class loader has a parent, it delegates the load request to the parent. Of course the parent could be the bootstrap class loader. In this case, no further delegations occur after delegating to the bootstrap loader.
• If the class is still not found, the loader calls the findClass() method on itself to locate the class. 

Bootstrap Class Loader

When the bootstrap loader is asked to load or find a class, it first searches the assemblies with which it is currently associated for the class. If found, it returns it. If it is not found, it then searches its class path for the class. When the bootstrap class loader is first initialized, it locates and reads the property file janet.bootclasspath found in jre\lib\boot.  The bootstrap loader then builds the class path it uses at runtime based on its contents.  If you look at the contents of the property file you will notice that it contains jar files, not assemblies as you might expect. This is because the bootstrap class loader uses the custom class loader support feature we have built into Ja.NET SE for class loading. If you�re interested on how this works, read our section on Custom Class Loaders in Ja.NET SE.

If you find a need to modify the bootstrap loaders class path, you can either edit the properties file mentioned above or, if you are using the Java launcher to start your application, you can use the -Xbootclasspath options to override the contents of the property file. The bootstrap class path is available as a system property by reading either vm.boot.class.path or sun.boot.class.path.

You will find that all of the bootstrap classes for Ja.NET SE are contained in several assemblies found in the jre\bin\default directory.  All of the classes implementing the Java API have been packaged into separate assemblies based on API functionality.  For example, you will find an assembly named janet.swing.dll in the directory. It contains all of the classes used to implement the swing functionality of the Java API.  Likewise you will find a corresponding set of jar files containing the Java classes for the Harmony VM located in the jre\lib\boot directory.

System and Extension Class Loaders

When the system and extension class loaders are asked to load a class, they first search their respective assemblies for the class. If the class is not found, they each delegate the call to their respective parent to see if it can load the class.  If the parent fails, they each search their respective class paths for the class. For the extensions class loader, its class path will include all jar, zip and assembly files found in the lib/ext directory. For the system class loader, its class path will default to the current directory for the application. If the CLASSPATH environment variable has been set, then that setting will override the default setting. If the application was launched using the java launcher, then the -cp option can be used to override either the default or the CLASSPATH environment setting. The system class path is available as a system property by reading java.class.path.

It is important to understand that as each of the loaders searches through their respective class paths looking for the class, the loaders will load each assembly into the process as they encounter them on their class paths.  This may not be the behavior you prefer as it could result in several assemblies being loaded that are never actually ever used.  You can use the custom class loader feature in Ja.NET SE to mitigate this behavior, if desired.