Chapter 9: Class Loaders Users can change the path for this mechanism by setting the java.endorsed.dirs property, as shown next. In fact, the Tomcat startup script has such a setting for changing the path of the endorsed directory to /endorsed: $ java -Djava.endorsed.dir=/path/to/lib/endorsed … Before developers start thinking about replacing all of the core libraries, an important limitation must be addressed: Only certain packages can be overridden. The complete list of packages is in the Java SE 1.5 documentation (http://java.sun.com/j2se/1.5.0/docs/guide/standards/). In short, only the CORBA classes and the JAXP classes can be overridden with this mechanism. More on Class Loader Behavior Now that we ve discussed the standard Java SE class loaders, as well as the delegation model that governs how these class loaders interact, the following sections address additional aspects of class loader behavior. Lazy Loading (Loading Classes on Demand) None of the three class loaders preloads all classes in the paths that they search for classes. Instead, they load the classes on demand. Such behavior is said to be lazy because the object waits to load the data until it is requested. While laziness in human beings is generally regarded as a negative trait, it is actually quite a positive one for class loaders, for the following reasons: . Faster performance: At the time of initialization, if each class loader had to load every class, it would take much longer to initialize the JVM. . Efficiency: Loading on demand results in more efficient memory usage because loading all the classes immediately would consume more memory than necessary. . Flexibility: JAR files and classes can be added to the search paths of all the class loaders even after the class loaders have been initialized. Note that when a class is loaded, all of its parent classes must also be loaded. Thus, if ClassB extends ClassA, and ClassB is loaded, then ClassA is also loaded. Class Caching The standard Java SE class loaders look up classes on demand, but once a class is loaded into a class loader, it will stay loaded (cached) for a period of time. However, the JVM s garbage collector can reclaim these Classobjects. This is generally desirable, unless one such garbage-collected Classobject is actually a stateful singleton class. (That is, a class that maintains a static reference to itself is either noninstantiable or not instantiated in practice, and maintains some aspects of an application s state.) For this reason, Sun JVMs allow class garbage collection to be turned off with the -Xnoclassgcoption. Separate Namespaces Each class loader is assigned a unique namespace. In other words, if the bootstrap class loader loads a class named sun.misc.ClassA, and the system class loader loads a class named sun.misc.ClassB , the
For high quality java hosting services please check java web hosting website.