Pregunta getClass (). getClassLoader () es nulo, ¿por qué?


Tengo un código que llama ...

x = getClass().getClassLoader();

Esto devuelve nulo sin embargo.

Cuando comienzo el mismo código no desde Eclipse, pero la línea de comando, devuelve un cargador de clases.

Puedo hackear el código para hacer esto ...

if (getClass().getClassLoader() == null)
{
 x = ClassLoader.getSystemClassLoader().getSystemResourceAsStream( loadedPropFileName );
} 

ambos se compilan y se ejecutan con la misma JVM. (Estoy 99.99% seguro).

¿Alguien tiene alguna idea de por qué la primera devolvería nulo para el cargador de clases?

Editar:

Mi pregunta es "¿Alguien tiene alguna idea de por qué la misma clase devolvería null cuando se inició a través de Eclipse y un cargador de clases cuando se carga desde la línea de comandos".

Gracias por el consejo de que el cargador Bootstap debe cargar la clase en Eclipse. Sin embargo, no tengo idea de por qué sucede esto.


32
2017-12-17 11:52


origen


Respuestas:


Citando el API doc:

Algunas implementaciones pueden usar null para   representar el cargador de clase de arranque.   Este método devolverá nulo en tal   implementaciones si esta clase era   cargado por el cargador de clase de arranque.


31
2017-12-17 11:59



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

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

Si Class se carga desde Extension Classpath, es decir; jdk \ jre \ lib \ ext * .jar, se llamará a Extension ClassLoader.

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

Como Bootstrap ClassLoader no está implementado en Java, está implementado en c o c ++, por lo que no hay referencia, por eso devuelve null. 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.

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


7
2017-09-26 05:22



"Este método devolverá nulo en tales implementaciones si esta clase fue cargada por el cargador de clases de arranque". http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html#getClassLoader ()


5
2017-12-17 12:00



Una cosa es cierta, Eclipse tiene una configuración de cargador de clases más profunda y más complicada que cuando se ejecuta desde la línea de comandos. Si ve diferencias en cómo el cargador de clases de una clase aparece en una frente a la otra, entonces esa es una razón bastante probable.

No conozco exactamente qué hace Eclipse, pero creo que es muy probable que su clase sea no que carga el cargador de clases de arranque cuando se ejecuta desde Eclipse, pero que Eclipse intenta hacer que parezca de esa manera.

El cargador de arranque ClassLoader es estático una vez que la aplicación se inicia y no se pueden agregar targets o clases más tarde a menos que Eclipse haya anulado la implementación ... en cuyo caso, hay otra posible explicación.


3
2017-12-18 00:49



Tuve el mismo problema. Pero lo resolvió usando:

<ClassName>.class.getClass().getResource(urlString);

Espero que esto ayude a otros ...


0
2017-10-03 16:35



"Este método devolverá nulo en tales implementaciones si esta clase fue cargada por el cargador de clases de arranque". - JavaDoc en getClassLoader ()

El cargador de clases nulo está reservado para clases de sistema por razones de seguridad y solo se puede usar si Class.forName (String name, boolean initialize, ClassLoader loader). Si una clase tiene un ClassLoader nulo, la mayoría de las comprobaciones de seguridad no se realizan.


0
2017-07-08 07:54



Tenía un problema similar. Resuelto al no usar el método getClass. Lo siguiente funcionó para mí.

<ClassName>.class.getClassLoader();

0
2018-06-28 12:03