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

eclipse

Question

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.

Answer 1

"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.

Answer 2

"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()

Answer 3

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, es decir; jdk / jre / lib / rt.jar, se llamará a BootStrap ClassLoader.

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

Si Class se carga desde Application ClassPath, es decir; 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ás null ya que BootStrap ClassLoader ha llamado a esta clase. Por otro lado, si haces lo mismo para una clase en Ext o App Class obtendrá $ ExtClassLoader @ someHexValue y sun.misc.Launcher$AppClassLoader@someHexValue respectivamente.

Answer 4

Citando el documento de API :

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.

Answer 5

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

<ClassName>.class.getClassLoader();

Answer 6

Tuve el mismo problema. Pero lo resolvió usando:

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

Espero que esto ayude a otros ...

Answer 7

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 el cargador de clases de arranque no cargue tu clase cuando se ejecuta desde Eclipse, sino que Eclipse intenta que parezca así.

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.