Class Loader di Java

1. Pengantar Class Loader

Pemuat kelas bertanggung jawab untuk memuat kelas Java selama runtime secara dinamis ke JVM (Java Virtual Machine). Juga, mereka adalah bagian dari JRE (Java Runtime Environment). Oleh karena itu, JVM tidak perlu mengetahui tentang file atau sistem file yang mendasarinya untuk menjalankan program Java berkat class loader.

Selain itu, kelas-kelas Java ini tidak dimuat ke dalam memori sekaligus, tetapi jika diperlukan oleh aplikasi. Di sinilah class loader berperan. Mereka bertanggung jawab untuk memuat kelas ke dalam memori.

Dalam tutorial ini, kita akan berbicara tentang berbagai jenis pemuat kelas bawaan, cara kerjanya, dan pengantar penerapan khusus kita sendiri.

2. Jenis Pemuat Kelas Bawaan

Mari kita mulai dengan mempelajari bagaimana berbagai kelas dimuat menggunakan berbagai pemuat kelas menggunakan contoh sederhana:

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()); }

Ketika dieksekusi, metode di atas mencetak:

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

Seperti yang dapat kita lihat, ada tiga pemuat kelas yang berbeda di sini; aplikasi, ekstensi, dan bootstrap (ditampilkan sebagai null ).

Loader kelas aplikasi memuat kelas tempat metode contoh berada. Pemuat kelas aplikasi atau sistem memuat file kita sendiri di classpath.

Selanjutnya, ekstensi memuat kelas Logging . Pemuat kelas ekstensi memuat kelas yang merupakan perpanjangan dari kelas inti Java standar.

Terakhir, bootstrap memuat kelas ArrayList . Bootstrap atau pemuat kelas primordial adalah induk dari semua pemuat lainnya.

Namun, kita dapat melihat bahwa keluaran terakhir, untuk ArrayList ini menampilkan null dalam keluaran. Ini karena pemuat kelas bootstrap ditulis dalam kode asli, bukan Java - jadi tidak muncul sebagai kelas Java. Karena alasan ini, perilaku pemuat kelas bootstrap akan berbeda di seluruh JVM.

Sekarang mari kita bahas lebih detail tentang masing-masing pemuat kelas ini.

2.1. Pemuat Kelas Bootstrap

Kelas Java dimuat dengan instance java.lang.ClassLoader . Namun, pemuat kelas adalah kelas itu sendiri. Oleh karena itu, pertanyaannya adalah, siapa yang memuat java.lang.ClassLoader itu sendiri ?

Di sinilah bootstrap atau loader kelas primordial masuk ke dalam gambar.

Ini terutama bertanggung jawab untuk memuat kelas internal JDK, biasanya rt.jar dan pustaka inti lainnya yang terletak di direktori $ JAVA_HOME / jre / lib . Selain itu, pemuat kelas Bootstrap berfungsi sebagai induk dari semua instance ClassLoader lainnya .

Pemuat kelas bootstrap ini adalah bagian dari inti JVM dan ditulis dalam kode asli seperti yang ditunjukkan pada contoh di atas. Platform yang berbeda mungkin memiliki implementasi yang berbeda dari loader kelas khusus ini.

2.2. Pemuat Kelas Ekstensi

The kelas ekstensi loader adalah anak dari class loader bootstrap dan mengurus memuat ekstensi dari kelas standar inti Jawa sehingga tersedia untuk semua aplikasi yang berjalan pada platform.

Loader kelas ekstensi dimuat dari direktori ekstensi JDK, biasanya direktori $ JAVA_HOME / lib / ext atau direktori lain yang disebutkan di properti sistem java.ext.dirs .

2.3. Loader Kelas Sistem

Sebaliknya, pemuat kelas sistem atau aplikasi menangani pemuatan semua kelas tingkat aplikasi ke dalam JVM. Ini memuat file yang ditemukan dalam variabel lingkungan classpath, opsi baris perintah -classpath atau -cp . Juga, ini adalah anak dari classloader Ekstensi.

3. Bagaimana Cara Kerja Pemuat Kelas?

Pemuat kelas adalah bagian dari Java Runtime Environment. Saat JVM meminta kelas, pemuat kelas mencoba untuk menemukan kelas dan memuat definisi kelas ke dalam runtime menggunakan nama kelas yang memenuhi syarat.

Metode java.lang.ClassLoader.loadClass () bertanggung jawab untuk memuat definisi kelas ke dalam runtime . Ia mencoba untuk memuat kelas berdasarkan nama yang memenuhi syarat.

Jika kelas tersebut belum dimuat, itu akan mendelegasikan permintaan ke pemuat kelas induk. Proses ini terjadi secara rekursif.

Akhirnya, jika pemuat kelas induk tidak menemukan kelas tersebut, maka kelas anak akan memanggil metode java.net.URLClassLoader.findClass () untuk mencari kelas-kelas dalam sistem file itu sendiri.

Jika pemuat kelas turunan terakhir juga tidak dapat memuat kelas, itu akan menampilkan java.lang.NoClassDefFoundError atau java.lang.ClassNotFoundException.

Mari kita lihat contoh keluaran saat ClassNotFoundException dilempar.

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)

Jika kita melalui urutan kejadian langsung dari memanggil java.lang.Class.forName () , kita dapat memahami bahwa pertama kali mencoba memuat kelas melalui loader kelas induk dan kemudian java.net.URLClassLoader.findClass () untuk mencari kelas itu sendiri.

Jika masih tidak menemukan kelas tersebut, ClassNotFoundException akan dilontarkan.

Ada tiga fitur penting dari pemuat kelas.

3.1. Model Delegasi

Pemuat kelas mengikuti model delegasi di mana atas permintaan untuk menemukan kelas atau sumber daya, instance ClassLoader akan mendelegasikan pencarian kelas atau sumber daya ke pemuat kelas induk .

Katakanlah kita memiliki permintaan untuk memuat kelas aplikasi ke dalam JVM. Loader kelas sistem pertama-tama mendelegasikan pemuatan kelas tersebut ke pemuat kelas ekstensi induknya yang kemudian mendelegasikannya ke pemuat kelas bootstrap.

Hanya jika bootstrap dan kemudian pemuat kelas ekstensi tidak berhasil memuat kelas, pemuat kelas sistem akan mencoba memuat kelas itu sendiri.

3.2. Kelas Unik

Sebagai konsekuensi dari model pendelegasian, mudah untuk memastikan kelas yang unik karena kami selalu mencoba untuk mendelegasikan ke atas .

Jika pemuat kelas induk tidak dapat menemukan kelas tersebut, hanya instance saat ini yang akan mencoba melakukannya sendiri.

3.3. Visibilitas

Selain itu, pemuat kelas turunan terlihat oleh kelas yang dimuat oleh pemuat kelas induknya .

Misalnya, kelas yang dimuat oleh pemuat kelas sistem memiliki visibilitas ke dalam kelas yang dimuat oleh ekstensi dan pemuat kelas Bootstrap tetapi tidak sebaliknya.

Untuk menggambarkan hal ini, jika Kelas A dimuat oleh pemuat kelas aplikasi dan kelas B dimuat oleh pemuat kelas ekstensi, maka kelas A dan B terlihat sejauh kelas lain dimuat oleh pemuat kelas Aplikasi yang bersangkutan.

Kelas B, bagaimanapun, adalah satu-satunya kelas yang terlihat sejauh kelas lain dimuat oleh pemuat kelas ekstensi yang bersangkutan.

4. ClassLoader Kustom

Pemuat kelas bawaan akan mencukupi di sebagian besar kasus di mana file sudah ada di sistem file.

Namun, dalam skenario di mana kita perlu memuat kelas dari hard drive lokal atau jaringan, kita mungkin perlu menggunakan pemuat kelas khusus.

Di bagian ini, kami akan membahas beberapa kasus penggunaan lain untuk pemuat kelas khusus dan kami akan menunjukkan cara membuatnya.

4.1. Kasus Penggunaan Loader Kelas Kustom

Pemuat kelas khusus berguna untuk lebih dari sekadar memuat kelas selama waktu proses, beberapa kasus penggunaan mungkin termasuk:

  1. Membantu dalam memodifikasi bytecode yang ada, misalnya agen tenun
  2. Membuat kelas secara dinamis sesuai dengan kebutuhan pengguna. misalnya di JDBC, peralihan antara implementasi driver yang berbeda dilakukan melalui pemuatan kelas dinamis.
  3. Mengimplementasikan mekanisme pembuatan versi kelas saat memuat bytecode berbeda untuk kelas dengan nama dan paket yang sama. Ini dapat dilakukan baik melalui pemuat kelas URL (memuat botol melalui URL) atau pemuat kelas khusus.

Ada lebih banyak contoh konkret di mana loader kelas khusus mungkin berguna.

Browser, misalnya, menggunakan pemuat kelas khusus untuk memuat konten yang dapat dijalankan dari situs web. Browser dapat memuat applet dari halaman web yang berbeda menggunakan pemuat kelas terpisah. Penampil applet yang digunakan untuk menjalankan applet berisi ClassLoader yang mengakses situs web di server jauh alih-alih mencari di sistem file lokal.

Dan kemudian memuat file bytecode mentah melalui HTTP, dan mengubahnya menjadi kelas di dalam JVM. Meskipun applet ini memiliki nama yang sama, mereka dianggap sebagai komponen yang berbeda jika dimuat oleh pemuat kelas yang berbeda .

Sekarang setelah kita memahami mengapa pemuat kelas khusus relevan, mari kita implementasikan subkelas ClassLoader untuk memperluas dan meringkas fungsionalitas cara JVM memuat kelas.

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.

Kami berbicara tentang berbagai jenis pemuat kelas yaitu - Bootstrap, Ekstensi, dan pemuat kelas Sistem. Bootstrap berfungsi sebagai induk untuk semuanya dan bertanggung jawab untuk memuat kelas internal JDK. Ekstensi dan sistem, di sisi lain, memuat kelas dari direktori ekstensi Java dan classpath masing-masing.

Kemudian kami berbicara tentang cara kerja pemuat kelas dan kami membahas beberapa fitur seperti pendelegasian, visibilitas, dan keunikan diikuti dengan penjelasan singkat tentang cara membuat pemuat khusus. Terakhir, kami menyediakan pengantar pemuat kelas Konteks.

Contoh kode, seperti biasa, dapat ditemukan di GitHub.