<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    敬的世界

    常用鏈接

    統計

    最新評論

    A Look At The Java Class Loader

    Class loading is one of the most poserful mechanisms provided by the Java Language Specification. All Java programmers should know the class loading mechanism works and what can be done to suit their needs. By understanding the class loading mechanism you can save time that would otherwise be spent on debugging ClassNotFoundException, ClassCastException . etc.

    Class Loaders

    In a Java Virtual Machine(JVM), each and every class is loaded by some instance of a java.lang.ClassLoader. The ClassLoader class is located in the java.lang.package and you can extend it to add your own functionality to class loading.

    When a new JVM is started by "java HelloWorld", the "bootstrap class loader" is responsible for loading key java classes like java.lang.Object and other runtime code into memory. The runtime classes are packaged inside jre/lib/rt.jar file. We cannot find the details of the bootstrap class loader in the java language specification, since this is a native implementation. For this reason the behavior of the bootstrap class loader will differ across JVM's.

    Maze Behind Loaders

    All class loaders are of the type java.lang.ClassLoader. Other than the bootstrap class loader all class loaders have a parent class loader. These two statements are different and are important for the correct working of any class loaders written by a developer. The most important aspect is to correctly set the parent class loader. The parent class loader for any class loader is the class loader instance that loaded that class loader.

    We have two ways to set the parent class loader:

    public class CustomClassLoader extends ClassLoader{
    ???
    ???public CustomClassLoader(){
    ??????super(CustomClassLoader.class.getClassLoader());
    ???}
    }
    or

    public class CustomClassLoader extedns ClassLoader{
    ???
    ???public CustomClassLoader(){
    ??????super(getClass().getClassLoader());
    ???}
    }

    The first constructor is the preferred one, because calling the method getClass() from within a constructor should be discouraged, since the object initialization will be complete only at the exit of the constructor code. Thus if the parent class loader is correct set, whenever a class is requested out of a ClassLoader instance using loadClass(String name) method, if it cannot find the class, it should ask the prent first. If the parent cannot find the class, the findClass(String name) method is invoked. The default implementation of findClass(String name) will throw ClassNotFoundException and developers are expected to implement this method when they subclass java.lang.ClassLoader to make custom class loaders.

    Inside the findClass(String name) method, the class loader needs to fetch the byte codes from some arbitrary source. The source may be a file system, a network URL, another application that can spit out byte codes on the fly, or any similar source that is capable of generating byte code compliant with the Java byte code specification. Once the byte code is retrieved, the method should call the defineClass() method, and the runtime is very particular about which instance of the ClassLoader is calling the method. Thus if two ClassLoader instances define byte codes from the same or different sources, the defined classes are different.

    For example, lets say I’ve a main class called MyProgram. MyProgram is loaded by the application class loader, and it created instances of two class loaders CustomClassLoader1 and CustomClassLoader2 which are capable of finding the byte codes of another class Student from some source. This means the class definition of the Student class is not in the application class path or extension class path. In such a scenario the MyProgram class asks the custom class loaders to load the Student class, Student will be loaded and Student.class will be defined independently by both CustomClassLoader1 and CustomClassLoader2. This has some serious implications in java. In case some static initialization code is put in the Student class, and if we want this code to be executed one and only once in a JVM, the code will be executed twice in the JVM with our setup, once each when the class is separately loaded by both CustomClassLoaders. If we have two instances of Student class loaded by these CustomClassLoaders say student1 and student2, then student1 and student2 are not type-compatible. In other words,

    Student student3 = (Student) student2;

    will throw ClassCastException, because the JVM sees these two as separate, distinct class types, since they are defined by different ClassLoader instances.

    The Need For Your Own Class loader

    For those who wish to control the JVM’s class loading behavior, the developers need to write their own class loader. Let us say that we are running an application and we are making use of a class called Student. Assuming that the Student class is updated with a better version on the fly, i.e. when the application is running, and we need to make a call to the updated class. If you are wondering that the bootstrap class loader that has loaded the application will do this for you, then you are wrong. Java’s class loading behavior is such that, once it has loaded the classes, it will not reload the new class. How to overcome this issue has been the question on every developers mind. The answer is simple. Write your own class loader and then use your class loader to load the classes. When a class has been modified on the run time, then you need to create a new instance of your class loader to load the class. Remember, that once you have created a new instance of your class loader, then you should make sure that you no longer make reference to the old class loader, because when two instances of the same object is loaded by different class loaders then they are treated as incompatible types.

    Writing Your Own Class loader

    The solution to control class loading is to implement custom class loaders. Any custom class loader should have java.lang.ClassLoader as its direct or distant super class. Moreover you need to set the parent class loader in the constructor. Then you have to override the findClass() method. Here is an implementation of a custom class loader.

    import java.io.DataInputStream;
    import java.io.File;
    import java.io.FileInputStream;
    import java.io.IOException;
    import java.util.Enumeration;
    import java.util.Hashtable;
    public class CustomClassLoader extends ClassLoader {
    public CustomClassLoader(){
    super(CustomClassLoader.class.getClassLoader());
    }

    public Class loadClass(String className) throws ClassNotFoundException {
    return findClass(className);
    }

    public Class findClass(String className){
    byte classByte[];
    Class result=null;
    result = (Class)classes.get(className);
    if(result != null){
    return result;
    }

    try{
    return findSystemClass(className);
    }catch(Exception e){
    }
    try{
    String classPath = ((String)ClassLoader.getSystemResource(className.replace('.',File.separatorChar)+".class").getFile()).substring(1);
    classByte = loadClassData(classPath);
    result = defineClass(className,classByte,0,classByte.length,null);
    classes.put(className,result);
    return result;
    }catch(Exception e){
    return null;
    }
    }

    private byte[] loadClassData(String className) throws IOException{

    File f ;
    f = new File(className);
    int size = (int)f.length();
    byte buff[] = new byte[size];
    FileInputStream fis = new FileInputStream(f);
    DataInputStream dis = new DataInputStream(fis);
    dis.readFully(buff);
    dis.close();
    return buff;
    }

    private Hashtable classes = new Hashtable();
    }

    Here is how to use the CustomClassLoader.

    public class CustomClassLoaderTest {

    public static void main(String [] args) throws Exception{
    CustomClassLoader test = new CustomClassLoader();
    test.loadClass(“com.test.HelloWorld”);
    }
    }

    Summary

    Many J2EE application servers have a “ hot deployment ” capability, where we can reload an application with a new version of class definition, without bringing the server VM down. Such application servers make use of custom class loaders. Even if we don’t use an application server, we can create and use custom class loaders to fine-control class loading mechanisms in our Java applications. So have fun with custom loaders

    posted on 2008-10-04 16:59 picture talk 閱讀(493) 評論(2)  編輯  收藏

    評論

    # re: A Look At The Java Class Loader 2008-12-03 16:41 gfdg

    help in executing the given code
    i am unable to compile the code
    i am getting error message as
      回復  更多評論   

    # re: A Look At The Java Class Loader 2009-10-08 01:30 picture talk

    @gfdg
    hi, what's wrong with it ? can you tell what the error message is ?  回復  更多評論   


    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    主站蜘蛛池模板: 亚洲情a成黄在线观看| 热久久精品免费视频| 无码人妻一区二区三区免费视频| 校园亚洲春色另类小说合集| 一级做性色a爰片久久毛片免费| 91精品成人免费国产| 16女性下面无遮挡免费| 免费观看激色视频网站bd| 国产精品色午夜免费视频| 亚洲AV日韩精品久久久久久| 日本亚洲免费无线码| 日日摸夜夜添夜夜免费视频 | 久久www免费人成看片| 亚洲VA中文字幕无码毛片| 国产v亚洲v天堂a无| 国产无遮挡又黄又爽免费网站| 在线看片无码永久免费视频| 亚洲午夜久久久影院| 亚洲欧美aⅴ在线资源| 在线成人爽a毛片免费软件| 亚洲男人天堂2020| 一级毛片免费在线播放| 国产国拍精品亚洲AV片 | 亚洲日韩av无码中文| 18禁无遮挡无码网站免费| 亚洲国产精品嫩草影院在线观看 | 亚洲中文字幕在线无码一区二区| 2022免费国产精品福利在线 | 亚洲无码一区二区三区| 亚洲精品在线免费观看| 亚洲偷自精品三十六区| 国产午夜免费福利红片| 亚洲另类自拍丝袜第1页| 中国一级特黄高清免费的大片中国一级黄色片| 国产a v无码专区亚洲av| 无码天堂va亚洲va在线va| 国产精品亚洲二区在线观看| 日韩人妻一区二区三区免费| 中文字幕在线亚洲精品| 中文字幕视频免费| 亚洲狠狠色丁香婷婷综合|