Clases de stock JDK y el ClassLoader "nulo"

Question

Hola chicos: estoy intentando depurar un error de clase muy extraño mirando el ClassLoader s para algunos componentes creados dinámicamente. ClassLoader s son algo con lo que nunca he jugado mucho, y me sorprende que las clases estándar de JDK tengan null instancias de cargador de clases.

Puede alguien explicar la salida de este sencillo método principal en términos de las clases cuyos cargadores que estoy tratando de imprimir, y también en términos más generales -

1. la forma ClassLoader s trabajo en la JVM y
2. cómo podemos depurar clases que faltan usando ClassLoader s.

public class MyClass { 

    /** 
    * @param args 
    */ 
    public static void main(String[] args) { 

     System.out.println(relfect.MyClass.class.getClassLoader()); 
     System.out.println(String.class.getClassLoader()); 
     System.out.println(ArrayList.class.getClassLoader()); 
     System.out.println(JButton.class.getClassLoader()); 
     System.out.println(System.class.getClassLoader()); 

     Boolean b = new Boolean(true); 
     System.out.println(b.getClass().getClassLoader()); 

    } 

} 

salida

sun.misc.Launcher$AppClassLoader@1f7182c1 
null 
null 
null 
null 
null 

Answer 1

el Javadoc para getClassLoader() dice

Devuelve el cargador de clases para la clase. Algunas implementaciones pueden usar null para representar el cargador de clases de arranque. Este método devolverá nulo en tales implementaciones si esta clase fue cargada por el cargador de clase bootstrap.

Por lo tanto, eso al menos explica por qué obtienes ese resultado. Pero no explica por qué los implementadores decidieron hacerlo de esa manera.

EDIT: Después de probar agregar mis propias clases a bootclasspath, también se muestran como cargador de clases nulo.

Answer 2

Classloader de las clases de arranque es nulo, no es una clase de Java.

No confundas las clases encontradas en el classpath y las cargadas por el cargador bootstrap. Este último es responsable de las clases básicas de JDK que generalmente se encuentran en rt.jar. Es un cargador de clases nativo, por lo tanto, no hay referencia hacia.

Las clases en el classpath las carga el cargador de clases del sistema, y ​​su clase se puede especificar a través de la propiedad.

Además, el cargador de clases nulo se considera un problema de seguridad y existen controles basados ​​en la clase de llamante que tiene el cargador de clases nulo.

Answer 3

Así es como funciona. Cada vez que JVM intenta cargar cualquier clase, se comprueba debajo de las condiciones.

Si la clase se carga desde Bootstrap ClassPath i.e; jdk \ jre \ lib \ rt.jar, se llamará a BootStrap ClassLoader.

Si la clase se carga desde Extension Classpath i.e; jdk \ jre \ lib \ ext * .jar, se llamará a Extension ClassLoader.

Si la clase se carga desde Application ClassPath i.e; como se especifica en Variable de entorno, se llama a Application ClassLoader.

Dado que Bootstrap ClassLoader no está implementado en Java, está implementado en c o en C++, por lo que no hay ninguna referencia para ello, por eso devuelve nulo. Pero el Cargador de clases de extensión y aplicación está escrito en java, por lo que obtendrá la referencia como sun.misc.Launcher$ExtClassLoader@someHexValue y sun.misc.Launcher$AppClassLoader@someHexValue.

Por lo tanto, si hace algo como esto System.out.println (String.class.getClassLoader()) obtendrá nulo ya que esta clase ha sido llamada por BootStrap ClassLoader, Por otro lado, si hace lo mismo para una clase en la ruta Ext o App Class obtendrás $ ExtClassLoader @ someHexValue y sun.misc.Launcher$AppClassLoader@someHexValue respectivamente.