Resumen

  • El README de pai-auth-ws-client conserva desde noviembre de 2024 el requisito «Java 8 o superior» y ejemplos que apuntan a la versión 1.0.0.
  • La serie publicada cambió en 1.5.0: el POM elevó java.version, source y target a 17. La 1.5.1 mantiene esa configuración y su CI usa JDK 17.
  • JitPack entrega el POM y el JAR 1.5.1. Las doce clases observadas tienen versión mayor 61 y el manifiesto identifica JDK 17.0.12; por tanto, no es una historia de artefacto ausente.
  • Una ficha por versión debería unir runtime mínimo, runtimes probados, revisión del documento y alcance de la API PAI, dejando la decisión de despliegue en manos de cada operador.

Cuando la dependencia resuelve, pero el runtime no alcanza

El problema aparece antes de que exista una petición de autenticación. Un equipo puede leer el repositorio de LACNIC, confirmar que su plataforma usa Java 8, copiar la configuración de JitPack y sustituir el 1.0.0 del ejemplo por la versión que anuncia el badge. El gestor de dependencias encontrará 1.5.1. El archivo llegará. Solo entonces el formato de sus clases impondrá Java 17.

El README facilita ese recorrido. Describe el proyecto como cliente Java del servicio web de autenticación PAI, fija Java 8 como mínimo y ofrece bloques para Maven y Gradle. Ambos usan 1.0.0, con un comentario legítimo: hay que reemplazarlo por una versión publicada en JitPack. El badge de esa misma página muestra hoy 1.5.1. Repositorio del cliente PAI README en 1.5.1 Proyecto en JitPack

JitPack sí sirve la versión. La descarga directa devolvió un POM y un JAR de 20.580 bytes. Dentro hay doce archivos de clase; todos contienen 61 en el campo de versión mayor. El manifiesto declara Build-Jdk: 17.0.12. La tabla normativa de la JVM asigna 52 a Java 8 y 61 a Java 17. Es el propio artefacto, no una inferencia a partir de un nombre, el que fija el umbral. POM generado 1.5.1 JAR 1.5.1 Especificación de la JVM

No se observó a ningún usuario seguir esos pasos. No hay evidencia de un login fallido, una interrupción, una incompatibilidad del servidor PAI, una brecha o una explotación. El hallazgo termina en la frontera de carga: la última biblioteca anunciada no tiene el nivel de clase que promete el requisito genérico.

La defensa de Java 17 merece ir primero

Elevar el runtime puede ser buena administración técnica. Java 8 es una base antigua; sostenerla de forma indefinida puede impedir actualizar dependencias o elevar el coste de mantener un cliente sensible. Un proyecto responsable puede decidir que la línea nueva requiere Java 17 y que la compatibilidad anterior queda en una rama vieja. El error sería convertir la compatibilidad histórica en una obligación perpetua.

Además, la release actual está ordenada por dentro. El POM 1.5.1 pone a 17 la propiedad de Java y los objetivos source y target. El workflow del mismo tag instala Zulu JDK 17 y ejecuta la verificación Maven. El JAR resultante usa major 61. Tres superficies independientes—configuración, proceso público de build y bytecode—coinciden. POM del tag 1.5.1 Workflow del tag 1.5.1

La primera release también conserva coherencia histórica. Su POM declara versión 1.0.0 y compila con source/target 1.8. El README parece haberse escrito para ese momento, y el comentario de los ejemplos no oculta que el número debe cambiar. POM del tag 1.0.0

La defensa, entonces, no niega la discrepancia; la explica. El código evolucionó con una decisión técnica razonable. La página de entrada no adquirió la información necesaria para que el lector sepa qué versiones siguen cumpliendo su promesa de Java 8.

El cambio tiene fecha de release

Los tags permiten reconstruir la frontera. Entre 1.1.0 y 1.4.0, los POM mantienen maven.compiler.source y maven.compiler.target en 1.8, aunque el workflow ya corre sobre JDK 17. Esos archivos también duplican la propiedad java.version: primero 1.8 y después 17. No conviene borrar esa rareza de la historia ni usarla como prueba de un fallo; los valores explícitos del compilador permanecen en 1.8.

En 1.5.0, los tres valores pasan claramente a 17. La 1.5.1 los conserva. Comparar el POM 1.4.0 con el 1.5.0 basta para localizar la subida del umbral. POM 1.4.0 POM 1.5.0

El README no tuvo una evolución paralela. Su historial muestra un único commit, del 1 de noviembre de 2024. El contenido comprobado es idéntico en todas las etiquetas revisadas y en main. GitHub publicó 1.5.0 el 29 de octubre de 2025 y 1.5.1 el 14 de abril de 2026. Los cuerpos de ambas releases están vacíos: no hay una nota pública sobre el salto a Java 17. Historial del README Lista de releases Release 1.5.1

No hace falta atribuir intención. Una guía estable y un código activo tienden a separarse si la compatibilidad no tiene un dueño visible en cada publicación.

Cinco pruebas, cinco preguntas

La plataforma de build no equivale al runtime mínimo. Compilar con JDK 17 puede producir clases para Java 8 si se configura una target anterior. El manual de Maven distingue source y target y advierte que esos parámetros no bastan por sí solos para garantizar todas las API disponibles. Por eso se inspeccionó el JAR. Guía de Maven Compiler

Pero el JAR tampoco responde todo. Major 61 prueba la generación mínima que entiende ese formato; no prueba con qué revisión del servicio PAI se hicieron las pruebas. El POM describe una intención de compilación; no prueba una autenticación. El workflow muestra una ejecución pública de CI; no describe una instalación de un miembro. La ficha de GitHub identifica una release; no garantiza que el artefacto sea soportado durante un plazo determinado.

Incluso la distribución exige cuidado. GitHub muestra cero assets adjuntos a 1.5.1, pero el proyecto usa JitPack y el JAR está disponible allí. La API de build de JitPack combina status: ok con el mensaje «Not found» y campos vacíos. Ese resultado es desconcertante, no decisivo: la descarga directa del artefacto prevalece para afirmar disponibilidad.

Separar las preguntas evita exageraciones. ¿La dependencia resolvió? ¿La JVM cargó la clase? ¿El cliente pudo inicializarse? ¿La API aceptó la petición? ¿La aplicación estableció la sesión? Cada paso produce un recibo distinto. Un problema en el primero no demuestra nada sobre la seguridad del último.

Lo mínimo que debería acompañar a cada versión

Una tabla de compatibilidad resolvería gran parte del problema. Cada fila puede incluir proyecto, tag, commit, coordenadas Maven, nivel de clase, JDK de build, runtime mínimo soportado y runtimes realmente probados. Debe añadir la revisión de la documentación aplicable, el alcance de versión de la API PAI, los cambios incompatibles, la ventana de soporte y un enlace a la corrección o sustitución.

La huella del artefacto sirve para anclar la fila a unos bytes. No hace falta convertir esta propuesta en un sistema de firmas, un estudio de builds reproducibles o una certificación del binario instalado. Tampoco debe identificar qué código corre en un servicio en vivo ni si una función está habilitada: esos mecanismos ya responden preguntas distintas.

La ficha puede decir «compilado con 17», «target 17» y «probado con 17/21» por separado. Puede declarar que 1.4.x sigue descargable pero no mantenida, o que una rama vieja recibe parches. Al conservar la historia, una corrección deja de reescribir el pasado.

LACNIC ya publica los componentes técnicos. Lo que falta es una unión pequeña y durable en el lugar donde se toma la decisión de versión.

Una promesa que viaja más lejos que el repositorio

La elección del runtime pertenece al operador. LACNIC no gobierna sus imágenes base, proveedores de JVM ni calendarios de renovación. Sin embargo, la frase pública se copia en inventarios, wikis, cuestionarios de proveedores y políticas automáticas. Cuando pierde el número de versión, se convierte en una condición aparentemente atemporal.

Una matriz protege a LACNIC de esa lectura y al operador de una sorpresa. Permite elevar el umbral sin confundir disponibilidad con soporte. Permite a una red pequeña calcular si puede adoptar una corrección antes de encontrarse bajo presión. Y permite que el soporte empiece por hechos comunes: tag, runtime y artefacto.

No hay que inmovilizar el software para conservar confianza. Hay que versionar la promesa con la misma disciplina que el software.

Sources

  1. LACNIC: repositorio del cliente PAI
  2. LACNIC: README de la versión 1.5.1
  3. LACNIC: POM de la versión 1.0.0
  4. LACNIC: POM de la versión 1.4.0
  5. LACNIC: POM de la versión 1.5.0
  6. LACNIC: POM de la versión 1.5.1
  7. LACNIC: workflow de build de la versión 1.5.1
  8. LACNIC: lista de releases en GitHub
  9. LACNIC: release 1.5.1
  10. LACNIC: historial de commits del README
  11. JitPack: proyecto del cliente PAI de LACNIC
  12. JitPack: POM generado de la versión 1.5.1
  13. JitPack: JAR de la versión 1.5.1
  14. Oracle: especificación de la JVM y formato de clases
  15. Apache Maven: configuración de source y target