Importar paquete. * Vs paquete de importación.Tipoespecífico

Question

¿Supondría alguna diferencia con respecto a la sobrecarga para escribir una importación cargando todos los tipos dentro de un paquete (import java.*); que simplemente un tipo específico (es decir, import java.lang.ClassLoader)? ¿El segundo sería una forma más recomendable de usar que el otro?

Answer 1

No hay un rendimiento ni gastos generales para realizar la importación. * Frente a la importación de tipos específicos. Sin embargo, considero que es una buena práctica nunca usar importación. * Mi razón principal para esto es que me gusta mantener las cosas claras, claras y con la menor ambigüedad posible, y creo que con una. * Importación, pierdes eso .

Answer 2

Una buena razón para no utilizar import xxx. * Es tener una visión clara de dependencies.

Puede saber más rápido que está utilizando una clase específica de otro paquete porque está en la lista justo al comienzo del archivo fuente.

Answer 3

Eche un vistazo a la API de Java, y verá muchas clases e interfaces con el mismo nombre en diferentes paquetes.

Por ejemplo:

java.lang.reflect.Array 
java.sql.Array 

Por lo tanto, si importa java.lang.reflect.* y java.sql.* tendrá una colisión en el tipo de matriz, y tiene que calificar totalmente en su código.

Importación de clases específicas en su lugar le ahorrará esta molestia.

Answer 4

Después de buscar más información, encontré este sitio web donde está muy bien explicado. Import issue y Does using * in an import statement affect performance?.

¿Hay algún problema de eficiencia entre estos dos estilos? Posiblemente, pero como las declaraciones de importación no importan nada en su programa, cualquier diferencia es muy pequeña. Recuerde que hay una implícita importación java.lang. * En la parte superior de sus unidades de compilación, y java.lang en JDK 1.2.2 contiene 75 clases e interfaces. Un experimento que utiliza un ejemplo artificial, uno con miles de usos de nombres de clases que deben buscarse, mostró un cambio insignificante en la velocidad de compilación. Por lo tanto, el rendimiento de compilación probablemente no se debe considerar un factor al elegir un formato sobre otro.

Existe un ángulo de interés final en declaraciones de importación. Supongamos que utiliza una clase interna:

package P; 

public class A { 
    public static class B {} 
} 

Si desea acceder a una de otra unidad de compilación, que dice:

import P.*; 

o: P.A importación; Pero si desea acceder a la B sin cualificación, lo que necesita decir:

import P.A.*; 

o: P.A.B importación; El primero de estos tipos disponibles dentro de la clase A que se encuentra en el paquete P. El segundo pone a disposición solo el tipo B encontrado en la clase A en el paquete P.

Answer 5

Tiendo a usar el IDE predeterminado. Encuentro que no es algo que realmente valga la pena preocuparse, ya que no tiene ningún impacto en el rendimiento, y la verificación de las dependencias se puede manejar con una variedad de herramientas.

Answer 6

Las importaciones no importan en el nivel de bytecode, por lo que no debería haber diferencia de tiempo de ejecución.

Encuentro que es mejor: a) Sea explícito al enumerar todas las importaciones b) Deje que su IDE lo administre. Cualquiera de los principales IDE puede actualizar, ordenar y completar automáticamente sus importaciones.

He encontrado a) para ser útil un par de veces al hacer reempaquetado manual fuera del contexto de una refactorización en IDE. Como, por ejemplo, cuando la comercialización cambia el nombre de su producto y decide que todos sus paquetes cambien de nombre.

Answer 7

Esto es realmente un problema muy malo.

Supongamos que escribe

import a.*; 
import b.*; 
... 
Foo f; 

y la clase Foo existe en un paquete.

Ahora comprueba tu código de compilación perfecto, y seis meses después, alguien agrega la clase Foo al paquete b. (Tal vez es una lib de un tercero que agregó clases en la última versión).

¡Poof! Ahora su código se niega a compilar.

Nunca use la importación a pedido. ¡Es malvado!

Ver http://javadude.com/articles/importondemandisevil.html para más detalles.

rendimiento RE:

import a.*; 

vs

import a.X; 

hace ninguna diferencia en tiempo de ejecución. El compilador conecta los nombres de clase resueltos en los archivos .class generados.

Answer 8

Minority view: en mi código Tiendo a usar toneladas de clases de algunos paquetes junto con algunas clases impares aquí y allá. Me gusta mantener mi lista de importaciones pequeña para poder decir lo que está pasando de un vistazo. Para hacer esto, configuré el umbral en 4 clases. Por encima de eso, Eclipse usará * para mi código. Encuentro esto mantiene legibles las importaciones de mi paquete, y tiendo a referirme a ellos como Lo primero que hago cuando miro una clase, para responder a la pregunta: ¿Con quién habla?

Relacionado con la colisión de nombres: ¿Cuáles son las posibilidades de que importe cuatro o más clases de dos paquetes que tienen nombres de clase competidores? Si es más del 10% del tiempo, es posible que desee considerar la cantidad de paquetes en los que confía su clase (por ejemplo, refactorizarlos en clases más pequeñas).

Answer 9

Es más una buena práctica de codificación ya que cualquier persona que lea su código sabrá inmediatamente qué clases utiliza una determinada clase con solo mirar el bloque de importación en la parte superior del archivo, mientras que debería buscar para ver si Usaste comodines.

Answer 10

Si está importando más de 20 clases del mismo paquete, es mejor utilizar import xxx. *. "Código limpio" está a favor de importar todo el paquete también.