Cambiar el nombre de Importar en Java, o importar dos clases con el mismo nombre


363

En Python puedes hacer:

from a import b as c

¿Cómo harías esto en Java, ya que tengo dos importaciones que están en conflicto?


19
Ojalá Java hiciera esto. Conduce a clases con nombres incómodos.
fncomp

2
@fncomp: ..y código desordenado con muchos
nombres de

2
Java 12 todavía no tiene esto
Janac Meena

Respuestas:


463

No existe un mecanismo de alias de importación en Java. No puede importar dos clases con el mismo nombre y usar ambas sin calificar.

Importe una clase y use el nombre completo para la otra, es decir

import com.text.Formatter;

private Formatter textFormatter;
private com.json.Formatter jsonFormatter;

16
Esa es la respuesta correcta y a eso solo agregaría lo que ha implicado: no, no hay tal sintaxis de alias en Java.
Sean Owen

19
¿Sigue siendo una limitación en Java 8?
HairOfTheDog

8
@HairOfTheDog Nope, desafortunadamente no se han agregado alias de importación en Java8
AdrieanKhisbe

12
Sí, estoy de acuerdo con tu comentario linuxdan ... Java ha seguido el camino del dinosaurio en términos de actualizaciones a su sintaxis.
Kevin Parker

66
@Bozho La forma de pitón hace: import [fully-qualified-name] as [ident]. El “como” no parece palabra clave para caber en Java, así, una alternativa es aproximadamente lo que # usos C: import [ident] = [fully-qualified-name].
Daniel H

60

Como las otras respuestas ya indicaron, Java no proporciona esta característica.

La implementación de esta función se ha solicitado varias veces, por ejemplo, como JDK-4194542: alias de nombre de clase o JDK-4214789: Extienda la importación para permitir el cambio de nombre del tipo importado .

De los comentarios:

Esta no es una solicitud irrazonable, aunque difícilmente esencial. El uso ocasional de nombres totalmente calificados no es una carga excesiva (a menos que la biblioteca realmente reutilice los mismos nombres simples a derecha e izquierda, lo cual es un mal estilo).

En cualquier caso, no pasa la barra de precio / rendimiento para un cambio de idioma.

Así que supongo que no veremos esta característica en Java pronto :-P


15
¡Guauu! no estabas bromeando acerca de "no (...) en el corto plazo", ¡veo que la solicitud de función fue rechazada como azúcar sin sentido desde 1998! Y cada intento de reabrir la discusión durante estos últimos 18 años se ha perdido en una referencia a esa antigua decisión. Supongo que sería más fácil convencer a los desarrolladores de IDE para que implementen esto como una máscara en el editor que tratar de darle sentido a Oracle.
Superole

2
Sin embargo, el viejo razonamiento es correcto: en la práctica, estos enfrentamientos rara vez ocurren.
delgado

14
No estoy de acuerdo en que estos enfrentamientos rara vez ocurren. La orientación a objetos favorece la simple denominación. Puedo tener una clase Empleado de dos bibliotecas diferentes que hacen cosas separadas con un empleado (por ejemplo).
Andrei Epure el

66
@slim " en la práctica, estos enfrentamientos rara vez ocurren ". No es claro por qué estas situaciones se producirían menos frecuencia en java (donde se puede tomar clases 10.000+) que en los otros idiomas (en la que por lo general tienen menos clases), que hacen apoyar esta sintaxis "azúcar".
Alain Pannetier

21
Absolutamente incorrecto Me enfrento a un escenario muy simple que probablemente es muy común y donde este azúcar sintáctico sería extremadamente útil. Traducción entre modelos de objetos relacionados, pero distintos (utilizados en productos relacionados pero diferentes, respectivamente) cuyas clases la mayoría de las veces comparten el mismo nombre. El proceso de traducción requiere que haga referencia a ambas clases en el mismo bloque de código. En tal caso (que debe ser muy común), Java hace la vida muy difícil. Solo la cantidad de visitas en esta publicación debería contarte la historia.
hrshi1990

59

Probablemente vale la pena señalar que Groovy tiene esta característica :

import java.util.Calendar
import com.example.Calendar as MyCalendar

MyCalendar myCalendar = new MyCalendar()

15
En Scala es:import com.example.{Calendar => MyCalendar}
pablisco

24
Y en Kotlin: import com.example.Calendar as MyCalendar.
KevinO

14
En PHP es: el uso com \ ejemplo \ calendario como MyCalendar
matang

19
Es bastante molesto ver que (al menos) 3 lenguajes basados ​​en JVM (Groovy, Scala y Kotlin) tienen esta característica, pero Java en sí todavía no ...
Matthias

2
¿Qué tal algo así class MyCalendar extends com.example.Calendar {}? No es ideal ni bonito, pero debería servir para la mayoría de los propósitos, excepto, por ejemplo, la reflexión. Incluso podría anteponerlo con un comentario si es necesario, como /* import com.example.Calendar as MyCalendar */.
Braden Best

21

Java no te permite hacer eso. Deberá referirse a una de las clases por su nombre completo y solo importar la otra.



-4

En realidad, es posible crear un acceso directo para que pueda usar nombres más cortos en su código haciendo algo como esto:

package com.mycompany.installer;
public abstract class ConfigurationReader {
    private static class Implementation extends com.mycompany.installer.implementation.ConfigurationReader {}
    public abstract String getLoaderVirtualClassPath();
    public static QueryServiceConfigurationReader getInstance() {
        return new Implementation();
    }
}

De esa manera, solo necesita especificar el nombre largo una vez, y puede tener tantas clases especialmente nombradas como desee.

Otra cosa que me gusta de este patrón es que puede nombrar la clase implementadora de la misma manera que la clase base abstracta, y simplemente colocarla en un espacio de nombres diferente. Sin embargo, eso no está relacionado con el patrón de importación / cambio de nombre.


18
Esta es una solución muy pobre. No trata completamente las estadísticas, puede requerir actualizaciones constantes y no ayuda con los problemas de deserialización (como la deserialización de xml a través de jaxb).
Ingeniero de software
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.