tipos - Diferencia entre usar nombre totalmente calificado e importar en Java
tipos de paquetes en java (6)
Solo importa en el siguiente caso,
Si quieres usar una clase que está disponible en paquetes múltiples. es decir, la clase de fecha está disponible en java.util y java.sql
Puede importar una de las clases anteriores al inicio del programa y usar la sintaxis calificada para otra.
¿Existen diferencias usando una "importación en línea" (un nombre completamente calificado) y una importación normal en términos de rendimiento, memoria, tiempo de compilación, etc. en Java?
chooser.setCurrentDirectory(new java.io.File("."));
y
import java.io.File;
...
chooser.setCurrentDirectory(new File("."));
En las clases de Java siempre se hace referencia por su nombre completo en el código de byte final. Sucede la primera vez cuando se crea un objeto de clase (o se accede a un miembro estático de la clase).
Dicho esto, el compilador utiliza la import
para acceder a las clases por su nombre no calificado ( MyClass
lugar de mypackage.MyClass
).
De modo que hay una diferencia de 0 entre importar la clase o escribir explícitamente el nombre completo: es solo cuestión de legibilidad, guarda algo de tipeo y ayuda a evitar conflictos entre clases con el mismo nombre.
Lo principal en lo que debes enfocarte es en la legibilidad. Encuentro el segundo más legible.
En casos raros, prefiero el segundo enfoque. Consideremos el siguiente escenario: por alguna razón, escribí una clase y lo llamé File
. Escribí File file = new File(...)
y mi IDE importó automáticamente java.io.File
para mí. Pero no quiero ese tipo de objeto, quiero mi clase de File
. Entonces, en lugar de importar la clase correcta, prefiero inline-import it, solo que otros usuarios no se confundirán con la clase File
de Java.
En cuanto al rendimiento, son exactamente lo mismo, y aquí está la prueba:
Este es el bytecode generado para el primer fragmento:
public class java8.tests.General {
public java8.tests.General();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class javax/swing/JFileChooser
3: dup
4: invokespecial #3 // Method javax/swing/JFileChooser."<init>":()V
7: astore_1
8: aload_1
9: new #4 // class java/io/File
12: dup
13: ldc #5 // String .
15: invokespecial #6 // Method java/io/File."<init>":(Ljava/lang/String;)V
18: invokevirtual #7 // Method javax/swing/JFileChooser.setCurrentDirectory:(Ljava/io/File;)V
21: return
}
Este es el bytecode para el segundo:
public class java8.tests.General {
public java8.tests.General();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class javax/swing/JFileChooser
3: dup
4: invokespecial #3 // Method javax/swing/JFileChooser."<init>":()V
7: astore_1
8: aload_1
9: new #4 // class java/io/File
12: dup
13: ldc #5 // String .
15: invokespecial #6 // Method java/io/File."<init>":(Ljava/lang/String;)V
18: invokevirtual #7 // Method javax/swing/JFileChooser.setCurrentDirectory:(Ljava/io/File;)V
21: return
}
Ninguno de los dos es exactamente igual en términos de rendimiento, memoria y tiempo de compilación. La única diferencia entre ellos es que la importación normal guarda tus esfuerzos de tipeo y es más legible que ''eso''.
No, no afectaría el rendimiento de tu código. Las declaraciones de importación hacen que su código sea más legible porque no está escribiendo todo el nombre de su paquete. Pero a veces, tiene un conflicto de ClassNames, entonces es aconsejable usar nombres calificados.
Si está importando clases del mismo nombre en una clase , puede indicar explícitamente cuál usar donde (nombre de clase completo):
import java.io.File;
...
chooser.setCurrentDirectory(new File(".")); // java.io.File
new org.yourpackage.File("sdfsdf"); // org.yourpackage.File