El lenguaje de programación Java se había diseñado para ser un lenguaje que funcionara sin tener que crear código específico para cada sistema donde se ejecutaba. También tenía algo que trataba de destacar frente a otros, que una vez “compilado” podía usarse el mismo “binario” en otras plataformas.
Sin embargo, los planes para este lenguaje cambiaron hace tiempo por diversos motivos, entre otros porque hay sistemas donde no se permite la ejecución de código privilegiado si no se tiene autorización del fabricante, como es el caso de Apple en su sistema operativo macOS.
En la actualidad los propios autores de Java invitan a distribuir la máquina virtual con el propio programa creado en este para que pueda ejecutarse. Esto desvirtúa la utilidad con la que fue diseñado, no teniendo mayores ventajas con respecto a otros lenguajes de programación que podrían considerarse más eficientes.
Hay diversos motivos por los que distribuir programas sin el entorno de ejecución de Java y su máquina virtual han quedado relegados a nichos muy particulares (por ejemplo, servlets de contenedores EE, applets de hardware empotrado y Android) y fuera del software tradicional de escritorio. Por ejemplo, para ejecutar programas en macOS sin bloqueos de seguridad por no estar firmados, siendo obligatorio si el programa se pretende distribuir en la App Store.
A partir de la versión Java 11 se ha eliminado la tecnología Web Start del entorno de ejecución. Tampoco hay un instalador para usuarios finales, por lo que Java 8 es el último que se ofrece en el sitio web java.com, como parte de esta transición. Una salida que tienen los distribuidores de software desarrollado en Java para ambientes de escritorio pasa por incluir un entorno de ejecución OpenJDK. En una entrada anterior de este blog ya se mencionó esta necesidad.
Cabe mencionar que existe software de escritorio muy dependiente de Java, como es el caso de la firma de documentos PDF, donde las mejores librerías para manipular documentos con este tipo de elementos están programadas en Java. La implementación de referencia del estándar PAdES (DSS) utiliza este lenguaje, ya que librerías como iText/OpenPDF y Apache PDFBox siguen siendo las mejores para este propósito.
Herramientas implementadas en Java como el Firmador de documentos que hemos realizado utilizan todavía Java para toda la interfaz. Incluso está disponible una versión Web Start de Firmador (requiere tener Java 8 instalado o bien OpenJDK con Icedtea-web), demostrando de la mejor forma una tecnología obsoleta. Hay planes de crear una versión de Firmador que utilice Java solamente para la parte que sea necesaria. El resto utilizaría otro lenguaje de programación más portable y eficiente.
Cabe mencionar que para utilizar la obsoleta tecnología Web Start se ha requerido firmar el código con un certificado digital específico que tiene un costo anual significativo, sin embargo ya era necesario hacerse uno para crear ejecutables sin que aparezca el fatídico mensaje de “Windows protegió su PC”, por lo que la inversión estaba pensada para este caso. Para el caso de macOS también hay que costear aparte otro certificado oneroso para distribuir software.
En cuanto al sector público, los firmadores ya distribuían el entorno de ejecución de Java con sus propios instaladores, por lo que ya están preparados para el fin de Java 8 en los próximos meses.