¿Cuál es la diferencia entre loadClass(String name) y loadClass(String name, boolean resolve)?Diferencia entre loadClass (String name) y loadClass (String name, boolean resolve)
La única diferencia que sé es que loadClass(String name, boolean resolve) llama a findLoadedClass (String) si el parámetro resolve es verdadero?
Entonces, ¿cuándo es verdadero o falso pasado al parámetro resolve?
Estoy confundido mucho entre estas dos funciones.
Gracias.
El parámetro resolve controla si la clase que se carga está vinculada o no. Durante la vinculación, las constantes estáticas se inicializan y se asigna su memoria. Además, se verifica la corrección de la clase y posiblemente se resuelvan los enlaces a otras clases.
Esto podría ser útil, por ejemplo, si desea cargar una nueva clase que puede estar mal formada y no desea que la JVM arroje errores de verificación en el caso de que la clase tenga errores.
La clase está vinculada de todos modos cuando se usa por primera vez (o al menos las piezas usadas): con el indicador resolve puede hacer que la VM haga esto vinculando (y arroje los errores relevantes) inmediatamente en lugar de hacerlo más tarde.
Puede intentarlo.
public class Test3 {
static{
new Test();
}
}
Después de compilar, cambiar la clase de prueba de una clase concreta a un interface.but permanecer enlace Test3 a una clase concreta a pruebas si la determinación es falsa, JVM no encontrará este error.It muy interesante. En realidad, Class someClass1= Class.forName("Test3",false,cls) tampoco resolverá Test3. Significa que no se lanzará ningún error.
Pero si establece la resolución verdadera en subClass o Class.forName("Test3"), entonces JVM en el tiempo de ejecución encontrará el error de enlace de clase.
Para su referencia, la especificación del lenguaje Java - 12.3 Linking of Classes and Interfaces explicar lo que hace resolveClass.
12,3 Linking de clases e interfaces La vinculación es el proceso de tomar una forma binaria de una clase o tipo de interfaz y la combinación en el estado de tiempo de ejecución de la máquina virtual Java, de modo que pueda ser ejecutado. Una clase o tipo de interfaz siempre se carga antes de vincularse. Tres actividades diferentes están involucradas en la vinculación: verificación, preparación y resolución de referencias simbólicas. La semántica precisa de vinculación se da en el capítulo 5 de la Especificación de máquina virtual de Java, segunda edición. Aquí presentamos una descripción general del proceso desde el punto de vista del lenguaje de programación Java.
12.3.3 Resolución de referencias simbólicas la representación binaria de una clase o interfaz Referencias Otras clases e interfaces y sus campos, métodos y constructores Simbólicamente, utilizando los nombres binarios (§13.1) de las otras clases e interfaces (§13.1). Para campos y métodos, estas referencias simbólicas incluyen el nombre de la clase o tipo de interfaz que declara el campo o método, así como el nombre del campo o método en sí, junto con la información de tipo apropiada. Antes de que se pueda usar una referencia simbólica, debe someterse a una resolución, donde se verifica que una referencia simbólica sea correcta y, por lo general, se reemplaza con una referencia directa que puede procesarse más eficientemente si la referencia se usa repetidamente.
Si se produce un error durante la resolución, se producirá un error. Más típicamente, esta será una instancia de una de las siguientes subclases de la clase IncompatibleClassChangeError, pero también puede ser una instancia de alguna otra subclase de IncompatibleClassChangeError o incluso una instancia de la clase IncompatibleClassChangeError. Este error puede ser lanzado en cualquier punto en el programa que utiliza una referencia simbólica con el tipo, directa o indirectamente:
IllegalAccessError: una referencia simbólica se ha encontrado que especifica un uso o asignación de un campo, o invocación de un método, o creación de una instancia de una clase, a la cual el código que contiene la referencia no tiene acceso porque el campo o método fue declarado privado, protegido o acceso predeterminado (no público) o porque la clase no fue declarada público. Esto puede ocurrir, por ejemplo, si un campo que originalmente se declaró público cambia a privado después de que se haya compilado otra clase que hace referencia al campo (§13.4.6).
InstantiationError: Se ha encontrado una referencia simbólica que se utiliza en una expresión de creación de instancia de clase, pero no se puede crear una instancia porque la referencia hace referencia a una interfaz o clase abstracta. Esto puede ocurrir, por ejemplo, si una clase que originalmente no es abstracta se cambia para que sea abstracta después de que se haya compilado otra clase que se refiere a la clase en cuestión (§13.4.1).
NoSuchFieldError: Se ha encontrado una referencia simbólica que hace referencia a un campo específico de una clase o interfaz específica, pero la clase o interfaz no contiene un campo de ese nombre. Esto puede ocurrir, por ejemplo, si se eliminó una declaración de campo de una clase después de que se compiló otra clase que hace referencia al campo (§13.4.7).
NoSuchMethodError: Se ha encontrado una referencia simbólica que hace referencia a un método específico de una clase o interfaz específica, pero la clase o interfaz no contiene un método de esa firma. Esto puede ocurrir, por ejemplo, si se eliminó una declaración de método de una clase después de que se compiló otra clase que hace referencia al método (§13.4.11). Además, se puede generar UnsatisfiedLinkError (una subclase de LinkageError) si una clase declara un método nativo para el que no se puede encontrar ninguna implementación. El error se producirá si se utiliza el método, o antes, según el tipo de estrategia de resolución que utilice la máquina virtual (§12.3).