Entrevista técnica: ¿Cómo evaluarías las Declaraciones de Importación de Módulos en Java 25?

Planteamiento y contexto

El equipo desea reducir las importaciones repetitivas en utilidades y ejemplos de Java, y planea utilizar Module Import Declarations en Java 25. Explica la semántica, los límites, el manejo de conflictos y las comprobaciones de migración en lugar de limitarte a repetir la nueva sintaxis.

Qué evalúa el entrevistador

• Saber que una importación de módulo importa los paquetes exportados por un módulo, no sus elementos internos arbitrarios.
• Explicar los descriptores de módulos, la legibilidad y la resolución de nombres en tiempo de compilación.
• Considerar los tipos con el mismo nombre, la precedencia de la importación explícita de un solo tipo y la legibilidad de la API.
• Proponer una estrategia de migración para JDKs más antiguos, herramientas de compilación y revisión de código.

Preguntas aclaratorias para hacer

1. ¿Cuál es el JDK de tiempo de ejecución mínimo y la cadena de compilación admite la sintaxis de Java 25?
2. ¿Se trata de un ejemplo didáctico, una utilidad de línea de comandos o un servicio modular de larga duración?
3. ¿Los módulos de dependencia exportan los paquetes necesarios de forma estable y varios paquetes exponen el mismo nombre de tipo público?
4. ¿El equipo valora más reducir el código repetitivo que hacer que cada dependencia sea auditable de inmediato?

Una respuesta de 30 segundos

Primero confirmaría que la compilación y el tiempo de ejecución tengan como objetivo Java 25 o posterior. Trataría import module como una importación por lotes de las APIs exportadas de un módulo, no como un comodín universal. Es adecuado para programas pequeños con dependencias estables y claras; las bibliotecas públicas y el código sensible a la seguridad aún necesitan una revisión de legibilidad con importaciones explícitas. Durante la migración compilaría cada conjunto de fuentes, agregaría pruebas intencionales de tipos con el mismo nombre, verificaría la precedencia de importaciones explícitas y mantendría una alternativa para JDKs anteriores o una puerta de actualización explícita.

Análisis detallado paso a paso

1. Comprender el límite de importación

La JEP 511 estandariza las declaraciones de importación de módulos en Java 25. La declaración incorpora tipos accesibles de los paquetes exportados por el módulo de destino a la unidad de compilación actual; un paquete interno no exportado no se vuelve visible. Las relaciones de requires y de legibilidad del sistema de módulos siguen rigiendo el acceso.

2. Distinguirlo de un comodín de paquete

Una importación de módulo utiliza un límite de módulo y puede cubrir varios paquetes exportados; un comodín de paquete cubre un solo paquete. La siguiente sintaxis debe compilarse con un compilador de Java 25:

import module java.base;

class Tool {
    static void printSize(String value) {
        System.out.println(value.length());
    }
}

Una importación de módulo no expone paquetes de implementación y no reemplaza las declaraciones de dependencia en un descriptor de módulo.

3. Resolver conflictos de nombres

Diferentes paquetes exportados pueden contener el mismo nombre de tipo. Cuando la resolución sea ambigua, utiliza una importación de un solo tipo o un nombre completo (fully qualified name); no dependas de una elección accidental del compilador. Haz de las importaciones explícitas una convención de equipo para que un revisor pueda ver el origen de las APIs importantes. Prueba las colisiones entre una importación de módulo y tipos implícitamente visibles, como los de java.lang.

4. Planificar la migración y la compatibilidad

Habilita primero la compilación de Java 25 en un conjunto de fuentes aislado y luego ejecuta las tareas completas de prueba, análisis estático y empaquetado. Verifica que los IDEs, formateadores, analizadores y compiladores incrementales comprendan la sintaxis; los proyectos de biblioteca deben evaluar el JDK mínimo de los consumidores. Si se siguen admitiendo versiones anteriores, mantén las importaciones explícitas o aísla la nueva sintaxis en un módulo exclusivo de Java 25 para que el riesgo de actualización en tiempo de ejecución no se propague a todos los servicios.

Respuesta modelo

Confirmaría que el JDK mínimo, el compilador y las herramientas de compilación admitan Java 25. import module importa tipos accesibles de paquetes exportados en el límite de un módulo; no puede acceder a elementos internos no exportados y no reemplaza a requires. Es adecuado para herramientas pequeñas, ejemplos o módulos con una superficie exportada estable. Las bibliotecas públicas y el código altamente auditado deben sopesar la reducción de código repetitivo frente a la visibilidad de las dependencias. Compilaría pruebas para tipos con el mismo nombre, colisiones con java.lang y precedencia de importaciones explícitas, y luego verificaría el IDE, los analizadores y la cadena de empaquetado. Los consumidores en JDKs anteriores mantienen las importaciones explícitas hasta que se verifiquen la puerta de actualización y la matriz de compatibilidad.

Errores comunes

• Suponer que una importación de módulo expone todos los paquetes dentro del módulo.
• Suponer que agrega automáticamente requires o cambia la legibilidad del módulo.
• Ignorar tipos con el mismo nombre en diferentes paquetes exportados, causando ambigüedad o el uso de la API incorrecta.
• Actualizar únicamente el JDK local sin verificar CI, IDEs, formateadores o herramientas de empaquetado.
• Usar importaciones por lotes a ciegas en bibliotecas públicas, reduciendo la auditabilidad y compatibilidad de las dependencias.
• Publicar sintaxis de Java 25 para consumidores que todavía ejecutan un JDK anterior.

Preguntas de seguimiento y respuestas

¿Cómo eliges entre una importación de módulo y un comodín de paquete?

Usa una importación de módulo cuando la dependencia deba expresarse en un límite de módulo estable; un comodín de paquete es más estrecho y más fácil de auditar localmente. Prefiere las importaciones explícitas de un solo tipo para APIs públicas o paquetes con muchos tipos con el mismo nombre.

¿Qué sucede cuando dos tipos importados tienen el mismo nombre?

Si coinciden varios candidatos, la compilación se vuelve ambigua. Utiliza una importación de un solo tipo o un nombre completo, y registra la convención en las guías de revisión de código en lugar de depender del orden de importación.

¿Cómo darías soporte a Java 21 y Java 25?

Crea una matriz de compilación clara. Las fuentes compartidas mantienen importaciones explícitas; solo un conjunto de fuentes específico para Java 25 utiliza importaciones de módulos. Antes del lanzamiento, verifica el bytecode, las pruebas y la versión mínima aceptada por cada consumidor.