Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Understanding the Java ClassLoading Mechanism: extend the Java platform This article was published in the Java Developer's Journal, August 2003. The journal discussed a key component known as the ClassLoading mechanism that is used by the Java Virtual Machine (JVM). What makes the ClassLoading mechanism so valuable is its custom usability to achieve functionality not normally achieved by any ordinary Java programs. The purpose of the JVM is very valuable when running and designing Java related programs. The JVM is used for loading and executing java code in classes using the mechanism mentioned, “ClassLoader”. When the IVM first initializes, it doesn’t need to know anything about any classes loaded at runtime from the help of the ClassLoading function; therefore, when implementing Java-based containers, it is very important to designers to know detailed information of how the ClassLoading function operates. The class file that is loaded into the ClassLoading mentioned above is a very small amount of execution. How the ClassLoading mechanism works is pretty 1 straightforward process. Every Java class file contains a binary representation of that class including everything the class does. The ClassLoading function simply takes this binary representation of these class files and locates the byte codes needed to be loaded. Then, it takes the loaded byte codes to be read. Finally, creates an instance of the java.lang.Class class. When the IVM is initialized, nothing is started, this process is the first step used by the IVM to get started. Technically, the starting class file that runs a program is executed first along with all its interfaces and other classes that are needed in the program. The JVM doesn’t load just any classes, it only loads classes when they are needed. Therefore, the IVM doesn’t need to know any classes to load up at startup. This type of “lazy loading” is a key aspect to the lava platform. On the Java 2 runtime environment there exist several instances of the ClassLoader method, each of these ClassLoader methods also load classes that are from different code repositories. Figure 1 shows an example of how this works with two examples of ClassLoader. Using examples, in most cases the Java API classes are loaded using the Bootstrap class loader and the Application classes are loaded using the System ClassLoader. Figure depicts a parent-child relationship between ClassLoaders. The Bootstrap ClassLoader is the only ClassLoader without a parent ClassLoader. The figure shows how Bootstrap is its own root of the tree and branches from there. 2 Described below is a short step-by-step algorithm that is ran by a ClassLoading function when the client wants to load a class: 1) First, to make sure a process is not duplicated, a simple check is ran to make sure the class was not already loaded by the ClassLoader. If, for some reason, the class was loaded already, then step one is already completed and then the JVM takes over. 2) If a previous ClassLoader has not loaded the class already, the process is then delegated to the ClassLoader’s parent before it can load the class. As seen in figure 1, delegation goes clear as far as the bootstrap ClassLoader but not any further. 3) A ClassLoader will try to search for a certain class usually only when a parent fails to return the class itself. Since this situation can occur, ClassLoaders have already defined locations to search for the missing class. 4) If all else fails and the class is still not found, the notorious 3 “java.lang.ClassNotFoundException” is thrown. In Figure 2 is a snippet of what methods for the ClassLoader would look like under the Java 2 API by extending the java.lang.Class Loader class. Before Java 2, implementing the ClassLoader method was fairly difficult and took time. Therefore, in Java 2 they came up with the parent delegation model to solve this problem as can be seen in Figure 1. However the algorithm mentioned above is just the standard algorithm, the great thing about the ClassLoading function is its ability to custom program the algorithm. There is a method the ClassLoader uses called findClass method. This is an original method used in step 3 in the above algorithm. 4 When a custom ClassLoader is created, it overwrites this findClass method with a custom way of finding and locating files thus resulting in a smoother implementation of a ClassLoader Figure 3 shows a listing of a piece of code of a custom ClassLoader program would look like to overwrite this findClass method. What the ClassLoader uses is the findClass method to find byte-codes of a class file. When these classes do get located and loaded, they can be now modified before calling the defineClass. The are several kinds of ClassLoaders existing to assist the JVM with different types of so called trust levels used in how they load classes into the JVM. For example, the Bootstrap ClassLoader has the highest trust level for its use in loading up the Java runtime libraries. Then the lower level of trust is used for user-defined ClassLoaders. How this happens, in either form, is when the class is loaded, the ClassLoaders imbeds permission rights to each class as it executes. To accomplish this task the custom ClassLoader should extend the java.security.SecureClassLoader class and use the method defineClass to be able to take a java.security.CodeSource object as a parameter. The JVM relies heavily on the ClassLoader function in bringing in code, and the build of the two mechanisms have a very strong security structure to protect the JVM from being able to communicate with the ClassLoader. It accomplishes this task when the ClassLoader loads a specific class and it gives it a unique name. When the runtime is ready to execute, it can identify this unique package name and what ClassLoader was used to create it. References Java Developer's Journal, August 2003 v8 i8 p10(3) 5 “Understanding the Java classloading mechanism: extend the Java platform.” (Java Architecture) Rohit Chaudhri. Liang, S., and Barcha, G. "Dynamic Class Loading in the Java Virtual Machine": www.java.su.com/people/grabracha/classloaders.pdf Venners, B. (2000).”Inside the Java Virtual Machine.” McGraw-Hill Osborne Media. Neward, T. (2000). “Server-Based Java Programming.” Manning Publications Company. Gong, Li. "Secure Java Class Loading" http://java.sun.com/people/gong/papers.ieeeic98.pdf The Java Servlet Specification: http://jcp.org/aboutJava/communityprocess/first/jsr154/ 6