Subprograma de Java

A Java applet que fue creado como material de demostración complementario para una publicación científica

A Java applet que utiliza aceleración de hardware 3D para visualizar archivos 3D. formato pdb descargado desde un servidor

Usando el applet para animación notrivial que ilustra el tema biofísico (los iones en movimiento aleatorio pasan por las puertas de tensión)

Utilizando un applet Java para computación – visualización intensiva del conjunto Mandelbrot

La velocidad de funcionamiento de Applets es suficiente para hacer, por ejemplo, juegos de computadora notrivial que juegan ajedrez.

NASA World Wind (fuente abierto) es un applet de segunda generación que hace un uso pesado de OpenGL y datos a pedido descargando para proporcionar un mapa 3D detallado del mundo.

Acceso web a la consola del servidor a nivel de hardware con la ayuda de un applet Java

Demostración del procesamiento de imágenes mediante la transformación de Fourier de dos dimensiones

Applets de Java eran pequeñas aplicaciones escritas en el lenguaje de programación Java, u otro lenguaje de programación que compila en el código de bytes de Java, y se entregaban a los usuarios en forma de código de bytes de Java. El usuario iniciaba el applet de Java desde una página web y luego se ejecutaba dentro de una máquina virtual de Java (JVM) en un proceso separado del propio navegador web. Un applet de Java podría aparecer en un marco de la página web, una nueva ventana de aplicación, AppletViewer de Sun o una herramienta independiente para probar applets.

Los subprogramas de Java se introdujeron en la primera versión del lenguaje Java, que se lanzó en 1995. A partir de 2013, los principales navegadores web comenzaron a eliminar gradualmente la compatibilidad con la tecnología subyacente utilizada para ejecutar los subprogramas, y los subprogramas se volvieron completamente incapaces de ser dirigido por 2015-2017. Los applets de Java quedaron obsoletos con Java 9 en 2017.

Los applets de Java generalmente se escribieron en Java, pero también se podrían usar otros lenguajes como Jython, JRuby, Pascal, Scala, NetRexx o Eiffel (a través de SmartEiffel).

Los applets de Java se ejecutan a velocidades muy rápidas y, hasta 2011, eran muchas veces más rápidos que JavaScript. A diferencia de JavaScript, los applets de Java tenían acceso a la aceleración de hardware 3D, lo que los hacía muy adecuados para visualizaciones no triviales con uso intensivo de cómputo. A medida que los navegadores han ganado soporte para gráficos acelerados por hardware gracias a la tecnología de lienzo (o específicamente WebGL en el caso de gráficos 3D), así como JavaScript compilado justo a tiempo, la diferencia de velocidad se ha vuelto menos notable.

Dado que el código de bytes de Java es multiplataforma (o independiente de la plataforma), los clientes pueden ejecutar applets de Java para muchas plataformas, incluidas Microsoft Windows, FreeBSD, Unix, macOS y Linux. No se pueden ejecutar en dispositivos móviles, que no admiten la ejecución del código de bytes JVM de Oracle estándar. Los dispositivos Android pueden ejecutar código escrito en Java compilado para Android Runtime.

Resumen

Los subprogramas se utilizan para proporcionar características interactivas a las aplicaciones web que HTML no puede proporcionar por sí solo. Pueden capturar la entrada del mouse y también tener controles como botones o casillas de verificación. En respuesta a las acciones del usuario, un subprograma puede cambiar el contenido gráfico proporcionado. Esto hace que los applets sean muy adecuados para la demostración, la visualización y la enseñanza. Hay colecciones de subprogramas en línea para estudiar varios temas, desde física hasta fisiología del corazón.

Un subprograma también puede ser solo un área de texto; proporcionando, por ejemplo, una interfaz de línea de comandos multiplataforma para algún sistema remoto. Si es necesario, un subprograma puede salir del área dedicada y ejecutarse como una ventana separada. Sin embargo, los subprogramas tienen muy poco control sobre el contenido de la página web fuera del área dedicada del subprograma, por lo que son menos útiles para mejorar la apariencia del sitio en general, a diferencia de otros tipos de extensiones de navegador (mientras que los subprogramas como los teletipos de noticias o los editores WYSIWYG son también conocido). Los applets también pueden reproducir medios en formatos que no son compatibles de forma nativa con el navegador.

Las páginas codificadas en HTML pueden incrustar parámetros dentro de ellas que se pasan al subprograma. Debido a esto, el mismo applet puede tener una apariencia diferente dependiendo de los parámetros que se hayan pasado.

Como los subprogramas estaban disponibles antes de HTML5, el CSS moderno y la interfaz de JavaScript DOM eran estándar, también se usaban ampliamente para efectos triviales como botones de desplazamiento y navegación. Este enfoque, que planteó grandes problemas de accesibilidad y mal uso de los recursos del sistema, ya no se usa y se desaconsejó enérgicamente incluso en ese momento.

Información técnica

La mayoría de los navegadores ejecutaban applets de Java en un sandbox, evitando que los applets accedieran a datos locales como el sistema de archivos. El código del subprograma se descargó de un servidor web, después de lo cual el navegador incrustó el subprograma en una página web o abrió una nueva ventana que mostraba la interfaz de usuario del subprograma.

Las primeras implementaciones consistían en descargar un applet clase por clase. Si bien las clases son archivos pequeños, a menudo hay muchos de ellos, por lo que los applets tienen la reputación de ser componentes de carga lenta. Sin embargo, desde que se introdujeron .jars, un subprograma generalmente se entrega como un solo archivo que tiene un tamaño similar a un archivo de imagen (cientos de kilobytes a varios megabytes).

Las bibliotecas y tiempos de ejecución del sistema Java son compatibles con versiones anteriores, lo que permite escribir código que se ejecuta tanto en versiones actuales como futuras de la máquina virtual Java.

Tecnologías similares

Muchos desarrolladores de Java, blogs y revistas recomendaron que se utilice la tecnología Java Web Start en lugar de applets. Java Web Start permitió el lanzamiento de código de subprograma sin modificar, que luego se ejecutó en una ventana separada (no dentro del navegador que invocaba).

A veces, un servlet de Java se compara informalmente con "como" un subprograma del lado del servidor, pero es diferente en su lenguaje, funciones y en cada una de las características descritas aquí sobre los subprogramas.

Incrustación en una página web

El subprograma se mostraría en la página web haciendo uso del elemento HTML applet en desuso, o el elemento object recomendado. El elemento embed se puede usar con los navegadores de la familia Mozilla (embed quedó obsoleto en HTML 4 pero se incluye en HTML 5). Esto especifica el origen y la ubicación del subprograma. Tanto las etiquetas object como embed también pueden descargar e instalar la máquina virtual Java (si es necesario) o al menos conducir a la página del complemento. Las etiquetas applet y object también admiten la carga de applets serializados que comienzan en algún estado particular (en lugar del inicial). Las etiquetas también especifican el mensaje que aparece en lugar del subprograma si el navegador no puede ejecutarlo por algún motivo.

Sin embargo, a pesar de que object era oficialmente una etiqueta recomendada en 2010, la compatibilidad de la etiqueta object aún no era uniforme entre los navegadores y Sun seguía recomendando la antigua etiqueta applet para implementar en entornos de múltiples navegadores, ya que sigue siendo la única etiqueta compatible de forma consistente con los navegadores más populares. Para admitir varios navegadores, usar la etiqueta object para incrustar un subprograma requeriría JavaScript (que reconoce el navegador y ajusta la etiqueta), el uso de etiquetas adicionales específicas del navegador o la entrega de resultados adaptados desde el lado del servidor.

El complemento del navegador Java se basaba en NPAPI, que casi todos los proveedores de navegadores web han eliminado o no implementan debido a su antigüedad y problemas de seguridad. En enero de 2016, Oracle anunció que los entornos de tiempo de ejecución de Java basados en JDK 9 descontinuarían el complemento del navegador.

Ventajas

Un applet de Java podría tener cualquiera o todas las siguientes ventajas:

• Fue sencillo hacer que funcionara en FreeBSD, Linux, Microsoft Windows y macOS, es decir, para hacerla multiplataforma. Los Applets fueron apoyados por la mayoría de los navegadores web a través de la primera década del siglo XXI; desde entonces, sin embargo, la mayoría de los navegadores han abandonado el soporte de applet por razones de seguridad.
• El mismo applet trabajaría en "todas" versiones instaladas de Java al mismo tiempo, en lugar de sólo la última versión plug-in. Sin embargo, si un applet requiere una versión posterior del Java Runtime Environment (JRE) el cliente sería obligado a esperar durante la descarga grande.
• La mayoría de los navegadores web caché applets para que fueran rápidos de cargar al regresar a una página web. Applets también mejoró con el uso: después de un primer applet se ejecuta, el JVM ya se estaba ejecutando y los siguientes applets comenzaron rápidamente (el JVM tendrá que reiniciar cada vez que el navegador comienza de nuevo). Las versiones de JRE 1.5 y mayor reiniciaron el JVM cuando el navegador navega entre páginas, como medida de seguridad que eliminó esa ganancia de rendimiento.
• Se movió el trabajo del servidor al cliente, haciendo una solución web más escalable con el número de usuarios/clientes.
• Si un programa independiente (como Google Earth) habla con un servidor web, ese servidor normalmente necesita apoyar todas las versiones anteriores para los usuarios que no han mantenido actualizado su software cliente. En cambio, un navegador carga (y encaje) la última versión de applet, por lo que no hay necesidad de soportar versiones heredadas.
• Applet apoyó naturalmente el cambio de estado de usuario, como posiciones de figura en el tablero de ajedrez.
• Los desarrolladores podrían desarrollar y depurar un applet directamente simplemente creando una rutina principal (ya sea en la clase del applet o en una clase separada) y llamando init() y start() en el applet, permitiendo así el desarrollo en su entorno de desarrollo Java SE favorito. Todo lo que tenía que hacer era volver a probar el applet en el programa AppletViewer o un navegador web para asegurar que se ajusta a las restricciones de seguridad.
• Un applet no confiable no tenía acceso a la máquina local y sólo puede acceder al servidor del que provenía. Esto hace que los applets sean mucho más seguros que los ejecutables nativos que reemplazarían. Sin embargo, un applet firmado podría tener acceso completo a la máquina que se está ejecutando, si el usuario estuvo de acuerdo.
• Los applets Java fueron rápidos, con un rendimiento similar al software instalado nativamente.

Desventajas

Los applets de Java tenían las siguientes desventajas en comparación con otras tecnologías web del lado del cliente:

• Los applets Java dependen de un Java Runtime Environment (JRE), un paquete de software complejo y pesado. También normalmente requieren un plug-in para el navegador web. Algunas organizaciones sólo permiten el software instalado por un administrador. Como resultado, los usuarios no pudieron ver applets a menos que uno fuera lo suficientemente importante para justificar el contacto con el administrador para solicitar la instalación del JRE y plug-in.
• Si un applet requiere un JRE más nuevo que disponible en el sistema, el usuario que lo ejecuta la primera vez tendrá que esperar a que la descarga JRE grande para completar.
• Los navegadores móviles en iOS o Android, nunca ejecutar aplicaciones Java en absoluto. Incluso antes de la depretación de los applets en todas las plataformas, los navegadores de escritorio eliminaron el soporte de manzana Java simultáneamente con el aumento de los sistemas operativos móviles.
• No había ningún estándar para poner el contenido de los applets a disposición de los lectores de pantalla. Por lo tanto, los folletos perjudicaron la accesibilidad de un sitio web a los usuarios con necesidades especiales.
• Al igual que con cualquier scripting del lado cliente, las restricciones de seguridad hicieron difícil o incluso imposible que algunos applets no confiados alcanzaran sus objetivos deseados. Sólo mediante la edición del archivo java.policy en la instalación JAVA JRE podría conceder acceso al sistema de archivos o portapapeles del sistema local, o a fuentes de red distintas a la que sirvió al applet al navegador.
• A la mayoría de los usuarios no les importaba la diferencia entre los applets no confiados y confiables, por lo que esta distinción no ayudaba mucho con la seguridad. La capacidad de ejecutar applets no confiables fue eliminada por completo para arreglar esto, antes de que se eliminaran todos los applets.

Demandas relacionadas con la compatibilidad

Sun hizo esfuerzos considerables para garantizar que se mantuviera la compatibilidad entre las versiones de Java a medida que evolucionaban, haciendo cumplir la portabilidad de Java por ley si fuera necesario. Oracle parece continuar con la misma estrategia.

1997: Sol contra Microsoft

La demanda de 1997 se presentó después de que Microsoft creara una máquina virtual Java modificada propia, que se envió con Internet Explorer. Microsoft agregó alrededor de 50 métodos y 50 campos en las clases dentro de los paquetes java.awt, java.lang y java.io. Otras modificaciones incluyeron la eliminación de la capacidad RMI y el reemplazo de la interfaz nativa de Java de JNI a RNI, un estándar diferente. RMI se eliminó porque solo admite fácilmente comunicaciones de Java a Java y compite con la tecnología Microsoft DCOM. Los applets que dependían de estos cambios o simplemente los usaban sin darse cuenta funcionaban solo dentro del sistema Java de Microsoft. Sun demandó por violación de marca registrada, ya que el objetivo de Java era que no debería haber extensiones propietarias y que el código debería funcionar en todas partes. Microsoft acordó pagarle a Sun $20 millones, y Sun acordó otorgarle a Microsoft una licencia limitada para usar Java solo sin modificaciones y por un tiempo limitado.

2002: Sol contra Microsoft

Microsoft siguió distribuyendo su propia máquina virtual Java sin modificar. A lo largo de los años, se volvió extremadamente obsoleto, pero sigue siendo el predeterminado para Internet Explorer. Un estudio posterior reveló que los applets de esta época a menudo contienen sus propias clases que reflejan Swing y otras características más nuevas de forma limitada. En 2002, Sun presentó una demanda antimonopolio alegando que los intentos de monopolización ilegal de Microsoft habían dañado la plataforma Java. Sun exigió a Microsoft que distribuyera la implementación binaria actual de la tecnología Java de Sun como parte de Windows, que la distribuyera como una actualización recomendada para los sistemas operativos de escritorio más antiguos de Microsoft y que detuviera la distribución de la máquina virtual de Microsoft (como su tiempo de licencia)., pactada en el pleito anterior, había caducado). Microsoft pagó 700 millones de dólares por problemas antimonopolio pendientes, otros 900 millones de dólares por problemas de patentes y una regalía de 350 millones de dólares para usar el software de Sun en el futuro.

Seguridad

Había dos tipos de subprogramas con modelos de seguridad muy diferentes: subprogramas firmados y subprogramas sin firmar. A partir de la actualización 21 de Java SE 7 (abril de 2013), se recomienda que los subprogramas y las aplicaciones Web-Start se firmen con un certificado de confianza, y aparecen mensajes de advertencia cuando se ejecutan subprogramas sin firmar. Además, a partir de Java 7 Update 51, los subprogramas sin firmar se bloquearon de forma predeterminada; podrían ejecutarse creando una excepción en el Panel de control de Java.

No firmada

Los límites de los subprogramas no firmados se interpretaron como "draconianos": no tienen acceso al sistema de archivos local y el acceso web está limitado al sitio de descarga del subprograma; también hay muchas otras restricciones importantes. Por ejemplo, no pueden acceder a todas las propiedades del sistema, usar su propio cargador de clases, llamar a código nativo, ejecutar comandos externos en un sistema local o redefinir clases pertenecientes a paquetes principales incluidos como parte de una versión de Java. Si bien pueden ejecutarse en un marco independiente, dicho marco contiene un encabezado, lo que indica que se trata de un subprograma que no es de confianza. La llamada inicial exitosa del método prohibido no crea automáticamente un agujero de seguridad ya que un controlador de acceso verifica toda la pila del código de llamada para asegurarse de que la llamada no provenga de una ubicación incorrecta.

Al igual que con cualquier sistema complejo, se han descubierto y solucionado muchos problemas de seguridad desde que se lanzó Java por primera vez. Algunos de estos (como el error de seguridad de serialización del calendario) persistieron durante muchos años sin que nadie lo supiera. Otros han sido descubiertos en uso por malware en la naturaleza.

Algunos estudios mencionan que los applets bloquean el navegador o abusan de los recursos de la CPU, pero estos se clasifican como molestias y no como verdaderas fallas de seguridad. Sin embargo, los subprogramas no firmados pueden estar involucrados en ataques combinados que explotan una combinación de múltiples errores de configuración graves en otras partes del sistema. Un subprograma no firmado también puede ser más peligroso si se ejecuta directamente en el servidor donde está alojado porque, si bien el código base le permite comunicarse con el servidor, ejecutarlo en su interior puede eludir el firewall. Un subprograma también puede intentar ataques DoS en el servidor donde está alojado, pero generalmente las personas que administran el sitio web también administran el subprograma, lo que hace que esto no sea razonable. Las comunidades pueden resolver este problema mediante la revisión del código fuente o ejecutando subprogramas en un dominio dedicado.

El subprograma sin firmar también puede intentar descargar malware alojado en el servidor de origen. Sin embargo, solo podría almacenar dicho archivo en una carpeta temporal (ya que son datos transitorios) y no tiene forma de completar el ataque ejecutándolo. Hubo intentos de usar subprogramas para difundir los exploits de Phoenix y Siberia de esta manera, pero estos exploits no usan Java internamente y también se distribuyeron de varias otras maneras.

Firmado

Un subprograma firmado contiene una firma que el navegador debe verificar a través de un servidor de autoridad certificadora independiente que se ejecute de forma remota. Producir esta firma involucra herramientas especializadas e interacción con los mantenedores del servidor de autoridad. Una vez que se verifica la firma, y el usuario de la máquina actual también la aprueba, un subprograma firmado puede obtener más derechos, convirtiéndose en equivalente a un programa independiente ordinario. La razón es que ahora se conoce al autor del subprograma y será responsable de cualquier daño deliberado. Este enfoque permite que los subprogramas se utilicen para muchas tareas que de otro modo no serían posibles mediante secuencias de comandos del lado del cliente. Sin embargo, este enfoque requiere más responsabilidad por parte del usuario, decidiendo en quién confía. Las preocupaciones relacionadas incluyen un servidor de autoridad que no responde, una evaluación incorrecta de la identidad del firmante al emitir certificados y editores de subprogramas conocidos que siguen haciendo algo que el usuario no aprobaría. Por lo tanto, los subprogramas firmados que aparecieron en Java 1.1 pueden tener más problemas de seguridad.

Autofirmado

Los subprogramas autofirmados, que son subprogramas firmados por el propio desarrollador, pueden representar un riesgo potencial para la seguridad; Los complementos de Java brindan una advertencia al solicitar autorización para un subprograma autofirmado, ya que la función y la seguridad del subprograma solo están garantizadas por el propio desarrollador y no se han confirmado de forma independiente. Dichos certificados autofirmados generalmente solo se usan durante el desarrollo antes del lanzamiento, donde la confirmación de seguridad por parte de terceros no es importante, pero la mayoría de los desarrolladores de subprogramas buscarán la firma de terceros para garantizar que los usuarios confíen en la seguridad del subprograma.

Los problemas de seguridad de Java no son fundamentalmente diferentes de los problemas similares de cualquier plataforma de secuencias de comandos del lado del cliente. En particular, todos los problemas relacionados con los subprogramas firmados también se aplican a los componentes de Microsoft ActiveX.

A partir de 2014, los complementos de Java comúnmente disponibles o Java Web Start ya no aceptan los subprogramas autofirmados y sin firmar. En consecuencia, los desarrolladores que deseen implementar applets de Java no tienen otra alternativa que adquirir certificados confiables de fuentes comerciales.

Alternativas

Existen tecnologías alternativas (por ejemplo, WebAssembly y JavaScript) que satisfacen todo o más del alcance de lo que era posible con un subprograma. JavaScript podría coexistir con los subprogramas en la misma página, asistir en el lanzamiento de los subprogramas (por ejemplo, en un marco separado o proporcionar soluciones alternativas a la plataforma) y luego ser llamado desde el código del subprograma. A medida que Javascript ganó en funciones y rendimiento, el soporte y el uso de applets declinaron, hasta que finalmente se eliminaron.