Chargeurs de classe en Java

1. Introduction aux chargeurs de classe

Les chargeurs de classes sont responsables du chargement dynamique des classes Java pendant l'exécution sur la JVM (Java Virtual Machine). En outre, ils font partie du JRE (Java Runtime Environment). Par conséquent, la JVM n'a pas besoin de connaître les fichiers ou les systèmes de fichiers sous-jacents pour exécuter des programmes Java grâce aux chargeurs de classe.

De plus, ces classes Java ne sont pas chargées en mémoire en même temps, mais lorsqu'elles sont requises par une application. C'est là que les chargeurs de classe entrent en scène. Ils sont responsables du chargement des classes en mémoire.

Dans ce didacticiel, nous allons parler de différents types de chargeurs de classe intégrés, de leur fonctionnement et d'une introduction à notre propre implémentation personnalisée.

2. Types de chargeurs de classe intégrés

Commençons par apprendre comment différentes classes sont chargées à l'aide de divers chargeurs de classes à l'aide d'un exemple simple:

public void printClassLoaders() throws ClassNotFoundException { System.out.println("Classloader of this class:" + PrintClassLoader.class.getClassLoader()); System.out.println("Classloader of Logging:" + Logging.class.getClassLoader()); System.out.println("Classloader of ArrayList:" + ArrayList.class.getClassLoader()); }

Lorsqu'elle est exécutée, la méthode ci-dessus imprime:

Class loader of this class:[email protected] Class loader of Logging:[email protected] Class loader of ArrayList:null

Comme nous pouvons le voir, il existe trois chargeurs de classe différents ici; application, extension et bootstrap (affichés comme null ).

Le chargeur de classe d'application charge la classe contenant l'exemple de méthode. Une application ou un chargeur de classe système charge nos propres fichiers dans le chemin de classe.

Ensuite, l'extension charge la classe Logging . Les chargeurs de classes d'extension chargent des classes qui sont une extension des classes Java de base standard.

Enfin, le bootstrap charge la classe ArrayList . Un bootstrap ou chargeur de classe primordial est le parent de tous les autres.

Cependant, nous pouvons voir que la dernière sortie, pour la ArrayList , affiche null dans la sortie. En effet, le chargeur de classe d'amorçage est écrit en code natif, pas en Java - il n'apparaît donc pas comme une classe Java. Pour cette raison, le comportement du chargeur de classe d'amorçage diffère selon les JVM.

Parlons maintenant plus en détail de chacun de ces chargeurs de classe.

2.1. Chargeur de classe Bootstrap

Les classes Java sont chargées par une instance de java.lang.ClassLoader . Cependant, les chargeurs de classes sont eux-mêmes des classes. Par conséquent, la question est de savoir qui charge le java.lang.ClassLoader lui - même ?

C'est là que le bootstrap ou le chargeur de classe primordial entre en scène.

Il est principalement responsable du chargement des classes internes JDK, généralement rt.jar et d'autres bibliothèques de base situées dans le répertoire $ JAVA_HOME / jre / lib . En outre, le chargeur de classe Bootstrap sert de parent de toutes les autres instances de ClassLoader .

Ce chargeur de classe bootstrap fait partie de la JVM principale et est écrit en code natif comme indiqué dans l'exemple ci-dessus. Différentes plates-formes peuvent avoir différentes implémentations de ce chargeur de classe particulier.

2.2. Chargeur de classe d'extension

Le chargeur de classe d'extension est un enfant du chargeur de classe d'amorçage et prend en charge le chargement des extensions des classes Java standard de base afin qu'il soit disponible pour toutes les applications exécutées sur la plate-forme.

Le chargeur de classe d'extension se charge à partir du répertoire des extensions JDK, généralement le répertoire $ JAVA_HOME / lib / ext ou tout autre répertoire mentionné dans la propriété système java.ext.dirs .

2.3. Chargeur de classe système

Le chargeur de classe système ou d'application, quant à lui, se charge de charger toutes les classes de niveau application dans la JVM. Il charge les fichiers trouvés dans la variable d'environnement CLASSPATH, -classpath ou -cp option de ligne de commande . En outre, il s'agit d'un enfant du chargeur de classe Extensions.

3. Comment fonctionnent les chargeurs de classe?

Les chargeurs de classes font partie de l'environnement d'exécution Java. Lorsque la machine virtuelle Java demande une classe, le chargeur de classe essaie de localiser la classe et de charger la définition de classe dans l'environnement d'exécution à l'aide du nom de classe qualifié complet.

La méthode java.lang.ClassLoader.loadClass () est responsable du chargement de la définition de classe dans le runtime . Il essaie de charger la classe en fonction d'un nom complet.

Si la classe n'est pas déjà chargée, elle délègue la demande au chargeur de classe parent. Ce processus se produit de manière récursive.

Finalement, si le chargeur de classe parent ne trouve pas la classe, la classe enfant appellera la méthode java.net.URLClassLoader.findClass () pour rechercher des classes dans le système de fichiers lui-même.

Si le dernier chargeur de classe enfant ne parvient pas non plus à charger la classe, il lance java.lang.NoClassDefFoundError ou java.lang.ClassNotFoundException.

Examinons un exemple de sortie lorsque ClassNotFoundException est levée.

java.lang.ClassNotFoundException: com.baeldung.classloader.SampleClassLoader at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348)

Si nous parcourons la séquence d'événements dès l'appel de java.lang.Class.forName () , nous pouvons comprendre qu'il essaie d'abord de charger la classe via le chargeur de classe parent, puis java.net.URLClassLoader.findClass () pour rechercher la classe elle-même.

Lorsqu'il ne trouve toujours pas la classe, il lève une exception ClassNotFoundException.

Il existe trois caractéristiques importantes des chargeurs de classe.

3.1. Modèle de délégation

Les chargeurs de classe suivent le modèle de délégation où, sur demande pour trouver une classe ou une ressource, une instance ClassLoader délègue la recherche de la classe ou de la ressource au chargeur de classe parent .

Let's say we have a request to load an application class into the JVM. The system class loader first delegates the loading of that class to its parent extension class loader which in turn delegates it to the bootstrap class loader.

Only if the bootstrap and then the extension class loader is unsuccessful in loading the class, the system class loader tries to load the class itself.

3.2. Unique Classes

As a consequence of the delegation model, it's easy to ensure unique classes as we always try to delegate upwards.

If the parent class loader isn't able to find the class, only then the current instance would attempt to do so itself.

3.3. Visibility

In addition, children class loaders are visible to classes loaded by its parent class loaders.

For instance, classes loaded by the system class loader have visibility into classes loaded by the extension and Bootstrap class loaders but not vice-versa.

To illustrate this, if Class A is loaded by an application class loader and class B is loaded by the extensions class loader, then both A and B classes are visible as far as other classes loaded by Application class loader are concerned.

Class B, nonetheless, is the only class visible as far as other classes loaded by the extension class loader are concerned.

4. Custom ClassLoader

The built-in class loader would suffice in most of the cases where the files are already in the file system.

However, in scenarios where we need to load classes out of the local hard drive or a network, we may need to make use of custom class loaders.

In this section, we'll cover some other uses cases for custom class loaders and we'll demonstrate how to create one.

4.1. Custom Class Loaders Use-Cases

Custom class loaders are helpful for more than just loading the class during runtime, a few use cases might include:

  1. Helping in modifying the existing bytecode, e.g. weaving agents
  2. Creating classes dynamically suited to the user's needs. e.g in JDBC, switching between different driver implementations is done through dynamic class loading.
  3. Implementing a class versioning mechanism while loading different bytecodes for classes with same names and packages. This can be done either through URL class loader (load jars via URLs) or custom class loaders.

There are more concrete examples where custom class loaders might come in handy.

Browsers, for instance, use a custom class loader to load executable content from a website. A browser can load applets from different web pages using separate class loaders. The applet viewer which is used to run applets contains a ClassLoader that accesses a website on a remote server instead of looking in the local file system.

And then loads the raw bytecode files via HTTP, and turns them into classes inside the JVM. Even if these applets have the same name, they are considered as different components if loaded by different class loaders.

Now that we understand why custom class loaders are relevant, let's implement a subclass of ClassLoader to extend and summarise the functionality of how the JVM loads classes.

4.2. Creating Our Custom Class Loader

For illustration purposes, let's say we need to load classes from a file using a custom class loader.

We need to extend the ClassLoader class and override the findClass() method:

public class CustomClassLoader extends ClassLoader { @Override public Class findClass(String name) throws ClassNotFoundException { byte[] b = loadClassFromFile(name); return defineClass(name, b, 0, b.length); } private byte[] loadClassFromFile(String fileName) { InputStream inputStream = getClass().getClassLoader().getResourceAsStream( fileName.replace('.', File.separatorChar) + ".class"); byte[] buffer; ByteArrayOutputStream byteStream = new ByteArrayOutputStream(); int nextValue = 0; try { while ( (nextValue = inputStream.read()) != -1 ) { byteStream.write(nextValue); } } catch (IOException e) { e.printStackTrace(); } buffer = byteStream.toByteArray(); return buffer; } }

In the above example, we defined a custom class loader that extends the default class loader and loads a byte array from the specified file.

5. Understanding java.lang.ClassLoader

Let's discuss a few essential methods from the java.lang.ClassLoader class to get a clearer picture of how it works.

5.1. The loadClass() Method

public Class loadClass(String name, boolean resolve) throws ClassNotFoundException {

This method is responsible for loading the class given a name parameter. The name parameter refers to the fully qualified class name.

The Java Virtual Machine invokes loadClass() method to resolve class references setting resolve to true. However, it isn't always necessary to resolve a class. If we only need to determine if the class exists or not, then resolve parameter is set to false.

This method serves as an entry point for the class loader.

We can try to understand the internal working of the loadClass() method from the source code of java.lang.ClassLoader:

protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { long t0 = System.nanoTime(); try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader } if (c == null) { // If still not found, then invoke findClass in order // to find the class. c = findClass(name); } } if (resolve) { resolveClass(c); } return c; } }

The default implementation of the method searches for classes in the following order:

  1. Invokes the findLoadedClass(String) method to see if the class is already loaded.
  2. Invokes the loadClass(String) method on the parent class loader.
  3. Invoke the findClass(String) method to find the class.

5.2. The defineClass() Method

protected final Class defineClass( String name, byte[] b, int off, int len) throws ClassFormatError

This method is responsible for the conversion of an array of bytes into an instance of a class. And before we use the class, we need to resolve it.

In case data didn't contain a valid class, it throws a ClassFormatError.

Also, we can't override this method since it's marked as final.

5.3. The findClass() Method

protected Class findClass( String name) throws ClassNotFoundException

This method finds the class with the fully qualified name as a parameter. We need to override this method in custom class loader implementations that follow the delegation model for loading classes.

Also, loadClass() invokes this method if the parent class loader couldn't find the requested class.

The default implementation throws a ClassNotFoundException if no parent of the class loader finds the class.

5.4. The getParent() Method

public final ClassLoader getParent()

This method returns the parent class loader for delegation.

Some implementations like the one seen before in Section 2. use null to represent the bootstrap class loader.

5.5. The getResource() Method

public URL getResource(String name)

This method tries to find a resource with the given name.

It will first delegate to the parent class loader for the resource. If the parent is null, the path of the class loader built into the virtual machine is searched.

If that fails, then the method will invoke findResource(String) to find the resource. The resource name specified as an input can be relative or absolute to the classpath.

It returns an URL object for reading the resource, or null if the resource could not be found or if the invoker doesn't have adequate privileges to return the resource.

It's important to note that Java loads resources from the classpath.

Finally, resource loading in Java is considered location-independent as it doesn't matter where the code is running as long as the environment is set to find the resources.

6. Context Classloaders

In general, context class loaders provide an alternative method to the class-loading delegation scheme introduced in J2SE.

Like we've learned before, classloaders in a JVM follow a hierarchical model such that every class loader has a single parent with the exception of the bootstrap class loader.

However, sometimes when JVM core classes need to dynamically load classes or resources provided by application developers, we might encounter a problem.

For example, in JNDI the core functionality is implemented by bootstrap classes in rt.jar. But these JNDI classes may load JNDI providers implemented by independent vendors (deployed in the application classpath). This scenario calls for the bootstrap class loader (parent class loader) to load a class visible to application loader (child class loader).

J2SE delegation doesn't work here and to get around this problem, we need to find alternative ways of class loading. And it can be achieved using thread context loaders.

The java.lang.Thread class has a method getContextClassLoader() that returns the ContextClassLoader for the particular thread. The ContextClassLoader is provided by the creator of the thread when loading resources and classes.

If the value isn't set, then it defaults to the class loader context of the parent thread.

7. Conclusion

Class loaders are essential to execute a Java program. We've provided a good introduction as part of this article.

Nous avons parlé de différents types de chargeurs de classe, à savoir - Bootstrap, extensions et chargeurs de classe système. Bootstrap sert de parent pour tous et est responsable du chargement des classes internes JDK. Les extensions et le système, en revanche, chargent les classes à partir du répertoire des extensions Java et du chemin de classe respectivement.

Ensuite, nous avons parlé du fonctionnement des chargeurs de classe et nous avons discuté de certaines fonctionnalités telles que la délégation, la visibilité et l'unicité, suivies d'une brève explication sur la façon de créer un chargeur personnalisé. Enfin, nous avons fourni une introduction aux chargeurs de classe Context.

Des exemples de code, comme toujours, peuvent être trouvés sur GitHub.