La API y las colecciones

La API de Java es el conjunto de clases e interfaces que vienen con la plataforma, organizadas en paquetes. Saberse la API de memoria no tiene sentido; lo que se pregunta, y lo que de verdad hace falta para trabajar, es saber en qué paquete vive cada cosa, porque el nombre del paquete es el índice de la biblioteca.

Una advertencia de nomenclatura que se paga cara en el examen: el prefijo javax no significa «antiguo» ni «obsoleto». Los paquetes javax de la edición estándar, como javax.sql o javax.xml.parsers, siguen llamándose así. Lo que cambió de javax a jakarta fue únicamente la edición empresarial, y se explica más adelante.

java.lang es el único paquete que no hace falta importar: sus clases están disponibles siempre. Por eso se puede escribir String, Object o System sin declarar nada al principio del fichero.

• java.lang: Object y Class, raíz e identidad de cualquier tipo; String, los envoltorios como Integer, Math, System para la salida por pantalla, Thread, y las interfaces Runnable e Iterable.
• java.lang, cadenas modificables: StringBuffer y StringBuilder construyen texto por partes sin crear un objeto nuevo en cada paso. La diferencia es que StringBuffer es seguro entre hilos y StringBuilder no, y por eso StringBuilder es más rápido cuando no hay concurrencia.
• java.net: Socket y ServerSocket para trabajar con TCP/IP a bajo nivel, URL y URLConnection para hablar HTTP, e InetAddress para resolver direcciones.
• java.sql: Driver y DataSource como puntos de entrada, Connection para la conexión, Statement y PreparedStatement para las sentencias, y ResultSet junto a ResultSetMetaData para recorrer y describir el resultado.
• java.text y java.util: DateFormat y SimpleDateFormat convierten entre texto y fecha en los dos sentidos; Calendar y Date son el modelo antiguo, superado primero por Joda-Time y después por java.time; Scanner lee de la entrada, StringTokenizer parte una cadena por un delimitador, Timer y TimerTask programan tareas y UUID genera identificadores únicos.
• javax.xml.parsers: DocumentBuilder implementa el análisis DOM, que carga el documento entero en memoria y permite recorrerlo en cualquier orden; SAXParser implementa el análisis SAX, que va lanzando eventos según lee y ocupa mucha menos memoria.
• java.io y java.nio: los flujos de bytes (InputStream y OutputStream) frente a los de caracteres (Reader y Writer); la interfaz Serializable, que marca una clase como convertible a una secuencia de bytes; y de java.nio, FileChannel, la clase de utilidad Files con operaciones sobre Path, y el WatchService, que avisa de los cambios que ocurren en un directorio.

Una colección es un objeto que agrupa otros objetos. Java las reúne en java.util con una jerarquía que conviene tener dibujada en la cabeza, porque casi todas las preguntas del apartado se resuelven sabiendo quién hereda de quién. En la cima está Iterable, la interfaz que permite recorrer algo elemento a elemento; de ella hereda Collection, y de Collection salen las tres familias.

Un array y una lista no son lo mismo aunque se parezcan: el array tiene tamaño fijo desde que se crea, mientras que un ArrayList crece y mengua solo. Ese es el motivo por el que casi nunca se programa con arrays salvo en casos muy concretos.

Map guarda parejas y no elementos sueltos, así que queda fuera de la jerarquía: ni Iterable ni Collection están por encima de él. Es la excepción del árbol y la pregunta más repetida sobre colecciones, y por eso se recorre a través de sus vistas (keySet, values, entrySet) y no directamente.

La clase de utilidad Arrays acompaña al marco de colecciones sin formar parte de él: opera sobre arrays y ofrece asList para convertir un array o una lista de argumentos en una List, binarySearch para buscar en un array ordenado, fill para rellenarlo y sort para ordenarlo. El número variable de argumentos que admite asList es lo que en Java se escribe con tres puntos suspensivos en la declaración del parámetro.

// un mapa de aciertos por subtema
Map<String, Integer> aciertos = new HashMap<>();
aciertos.put("jakarta-ee", 8);
aciertos.put("plataforma-net", 6);

Integer deJakarta = aciertos.get("jakarta-ee");   // 8
Set<String> subtemas = aciertos.keySet();         // las claves
Collection<Integer> notas = aciertos.values();    // los valores

// recorrer un mapa: por sus pares, no por el mapa
for (Map.Entry<String, Integer> par : aciertos.entrySet()) {
    System.out.println(par.getKey() + ": " + par.getValue());
}

Maven es una herramienta escrita en Java que hace dos trabajos a la vez. El primero es automatizar la construcción: localizar el código fuente y los ficheros de configuración, compilarlos, pasar las pruebas y empaquetar el resultado. El segundo, y el que de verdad cambió la forma de trabajar, es gestionar las dependencias: declarar qué bibliotecas necesita el proyecto y dejar que la herramienta las descargue de un repositorio.

Todo se declara en un único fichero, el POM (Project Object Model), que es el pom.xml del proyecto. Las bibliotecas descargadas se guardan en un repositorio local en la máquina de quien desarrolla, y el repositorio público de referencia es el de la propia Apache. Existen además arquetipos, que son plantillas para crear un proyecto nuevo ya con su estructura.

Cada biblioteca se identifica con tres coordenadas, y esa terna es lo que se pregunta: groupId (quién la publica), artifactId (qué biblioteca es) y version (cuál de sus versiones). El fabricante es dueño de su groupId y de sus artifactId, así que dos bibliotecas distintas nunca chocan.

<!-- una dependencia del proyecto, en pom.xml -->
<dependency>
  <groupId>com.llegandoalcorte</groupId>
  <artifactId>motor-de-repasos</artifactId>
  <version>2.4.0</version>
</dependency>

groupId, artifactId y version. Con esas tres coordenadas se localiza cualquier artefacto en cualquier repositorio, y por eso una dependencia declarada así se resuelve igual en el portátil de quien programa que en el servidor de integración.

Maven impone una disposición de carpetas fija, y esa imposición es deliberada: como todos los proyectos se organizan igual, la herramienta no necesita que se le explique dónde está cada cosa y quien llega nuevo a un proyecto sabe orientarse sin preguntar. El código fuente de la aplicación vive bajo src/main/java, y el resultado de la construcción se deja en target.

La construcción está organizada en fases encadenadas, de modo que pedir una fase ejecuta también todas las anteriores. Por eso una sola orden de empaquetado compila, pasa las pruebas y genera el .jar o el .war, sin necesidad de ir paso a paso.

# se lanza desde el directorio donde está el pom.xml
mvn package

# la disposición fija de carpetas
#   pom.xml
#   src/main/java        código de la aplicación
#   src/main/resources   configuración y recursos
#   src/test/java        pruebas
#   target/              lo construido

Un detalle que se pregunta a menudo: cada dependencia se declara con una versión concreta, no con «la última». Es lo que hace que una construcción de hoy y otra de dentro de dos años den el mismo resultado. Y una comparación clásica: Maven y Ant son las dos de Apache, pero Ant se limita a automatizar tareas y no gestiona dependencias, que es justo lo que Maven añadió.

Alrededor de la plataforma hay un ecosistema que en la práctica forma parte del trabajo diario. Conviene tenerlo ordenado por función, que es como se pregunta: dado un nombre, para qué sirve.

Ninguno de estos nombres forma parte de la plataforma: son piezas de terceros que se incorporan como dependencias del proyecto. Esa es justamente la razón de existir de un gestor como Maven, y por eso los dos puntos se estudian juntos.