Los applets de Java son pequeñas aplicaciones escritas en el lenguaje de programación Java u otro lenguaje de programación que se compila en bytecode de Java y se entrega a los usuarios en forma de bytecode de Java . Los applets quedaron obsoletos en Java 9 en 2017.
En el momento de su introducción, el uso previsto era que el usuario lanzara el subprograma desde una página web y que éste se ejecutara dentro de una máquina virtual Java (JVM) en un proceso separado del propio navegador web . Un subprograma Java podría aparecer en un marco de la página web, en una nueva ventana de aplicación, en un programa de Sun llamado appletviewer [6] o como una herramienta independiente para probar subprogramas. [ Aclaración necesaria ]
Los applets 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 el soporte para NPAPI , la tecnología subyacente que usaban los applets para ejecutarse, y los applets dejaron de poder ejecutarse por completo entre 2015 y 2017. Los applets de Java quedaron obsoletos en Java 9 en 2017. [7] [8] [9] [10] [11]
Los applets de Java generalmente se escribían en Java, pero también se podían utilizar otros lenguajes como Jython , JRuby , Pascal , [12] Scala , NetRexx o Eiffel (a través de SmartEiffel ).
Los applets de Java se ejecutan a velocidades muy rápidas [ cita requerida ] y hasta 2011, eran mucho más rápidos que JavaScript . [ cita requerida ] A diferencia de JavaScript, los applets de Java tenían acceso a la aceleración de hardware 3D , lo que los hacía adecuados para visualizaciones no triviales que requieren un uso intensivo de los recursos computacionales. A medida que los navegadores han ganado soporte para gráficos acelerados por hardware gracias a la tecnología canvas (o específicamente WebGL en el caso de gráficos 3D), [13] [14] así como también para JavaScript compilado justo a tiempo , [15] la diferencia de velocidad se ha vuelto menos notoria. [ cita requerida ]
Dado que el bytecode 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 pueden ejecutarse en dispositivos móviles, que no admiten la ejecución del bytecode estándar de Oracle JVM. Los dispositivos Android pueden ejecutar código escrito en Java compilado para Android Runtime .
Los subprogramas se utilizan para proporcionar funciones interactivas a las aplicaciones web que no se pueden proporcionar solo con HTML . Pueden capturar la entrada del ratón y también tienen 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 subprogramas sean adecuados para demostraciones, visualización y enseñanza. Existen colecciones de subprogramas en línea para estudiar diversos temas, desde física hasta fisiología cardíaca.
Un subprograma también puede ser solo un área de texto, proporcionando, por ejemplo, una interfaz de línea de comandos multiplataforma a algún sistema remoto. Si es necesario, un subprograma puede abandonar el á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 al subprograma, por lo que son menos útiles para mejorar la apariencia del sitio en general, a diferencia de otros tipos de extensiones del navegador (aunque también se conocen subprogramas como los teletipos de noticias o los editores WYSIWYG ). Los subprogramas también pueden reproducir medios en formatos que no son compatibles de forma nativa con el navegador.
Las páginas codificadas en HTML pueden incluir parámetros que se pasan al subprograma. Por este motivo, el mismo subprograma puede tener una apariencia diferente según los parámetros que se hayan pasado.
Como los applets ya estaban disponibles antes de HTML5 , el CSS moderno y el DOM de interfaz de JavaScript eran estándar, también se usaban ampliamente para efectos triviales como botones de navegación y al pasar el ratón por encima . Este enfoque, que planteaba grandes problemas de accesibilidad y mal uso de los recursos del sistema, ya no se utiliza y se desaconsejó enérgicamente incluso en su momento.
La mayoría de los navegadores ejecutaban applets de Java en una zona protegida , lo que impedía que los applets accedieran a datos locales como el sistema de archivos . [16] El código del applet se descargaba desde un servidor web , después de lo cual el navegador incrustaba el applet en una página web o abría una nueva ventana que mostraba la interfaz de usuario del applet .
Las primeras implementaciones implicaban la descarga de un subprograma clase por clase. Si bien las clases son archivos pequeños, a menudo hay muchas, por lo que los subprogramas se ganaron la reputación de ser componentes de carga lenta. Sin embargo, desde que .jarse introdujeron los archivos, un subprograma suele entregarse como un único archivo que tiene un tamaño similar al de un archivo de imagen (cientos de kilobytes a varios megabytes).
Las bibliotecas y los entornos de ejecución del sistema Java son compatibles con versiones anteriores, lo que permite escribir código que se ejecute tanto en la versión actual como en las futuras de la máquina virtual Java.
Muchos desarrolladores, blogs y revistas de Java recomendaron que se utilizara la tecnología Java Web Start en lugar de applets. [17] Java Web Start permitía el lanzamiento de código de applet sin modificar, que luego se ejecutaba en una ventana separada (no dentro del navegador que lo invocaba).
A veces se compara informalmente a un servlet de Java con "similar" a 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.
El subprograma se mostraría en la página web haciendo uso del appletelemento HTML obsoleto, [18] o el objectelemento recomendado. [19] El embedelemento se puede usar [20] con los navegadores de la familia Mozilla ( embedquedó obsoleto en HTML 4 pero está incluido en HTML 5). Esto especifica la fuente y la ubicación del subprograma. Tanto las etiquetas objectcomo embedtambién pueden descargar e instalar la máquina virtual Java (si es necesario) o al menos llevar a la página del complemento. Las etiquetas applety objecttambién admiten la carga de los subprogramas serializados que comienzan en un 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 objectser oficialmente una etiqueta recomendada en 2010, el soporte de la objectetiqueta aún no era consistente entre los navegadores y Sun siguió recomendando la appletetiqueta más antigua para implementar en entornos multinavegador, [21] ya que seguía siendo la única etiqueta compatible de manera consistente con los navegadores más populares. Para admitir varios navegadores, el uso de la objectetiqueta 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 una salida adaptada desde el lado del servidor.
El complemento del navegador Java dependía de NPAPI , para el cual casi todos los proveedores de navegadores web han eliminado el soporte o no lo implementan debido a su antigüedad y problemas de seguridad. En enero de 2016, Oracle anunció que los entornos de ejecución de Java basados en JDK 9 descontinuarían el complemento del navegador. [22]
Un subprograma Java podría tener cualquiera o todas las siguientes ventajas: [23]
Los applets de Java tenían las siguientes desventajas en comparación con otras tecnologías web del lado del cliente:
Sun ha hecho esfuerzos considerables para garantizar que se mantenga la compatibilidad entre las versiones de Java a medida que evolucionan, imponiendo por ley la portabilidad de Java en caso de ser necesario. Oracle parece seguir con la misma estrategia.
La demanda de 1997, [25] fue interpuesta después de que Microsoft creara una máquina virtual Java modificada propia , que se incluía con Internet Explorer. Microsoft añadió unos 50 métodos y 50 campos [25] a 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 fue eliminado porque sólo admite fácilmente las comunicaciones de Java a Java y compite con la tecnología DCOM de Microsoft . Los applets que dependían de estos cambios o simplemente los utilizaban inadvertidamente funcionaban sólo 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ó pagar a Sun 20 millones de dólares, y Sun acordó conceder a Microsoft una licencia limitada para utilizar Java sin modificaciones únicamente y por un tiempo limitado. [26]
Microsoft siguió distribuyendo su propia máquina virtual Java sin modificar. Con el paso de los años se volvió extremadamente obsoleta, pero aún así seguía siendo la predeterminada para Internet Explorer. Un estudio posterior reveló que los applets de esta época a menudo contenían sus propias clases que reflejaban Swing y otras características más nuevas de forma limitada. [27] En 2002, Sun presentó una demanda antimonopolio , alegando que los intentos de Microsoft de monopolización ilegal habían dañado la plataforma Java. Sun exigió que Microsoft distribuyera la implementación binaria actual de la tecnología Java de Sun como parte de Windows, la distribuyera como una actualización recomendada para los sistemas operativos de escritorio más antiguos de Microsoft y detuviera la distribución de la máquina virtual de Microsoft (ya que el tiempo de licencia, acordado en la demanda anterior, había expirado). [26] Microsoft pagó 700 millones de dólares por problemas antimonopolio pendientes, otros 900 millones de dólares por problemas de patentes y una tarifa de regalías de 350 millones de dólares para usar el software de Sun en el futuro. [28] [ fuente no primaria necesaria ]
Había dos tipos de applets con modelos de seguridad muy diferentes: applets firmados y applets no firmados. [29] A partir de Java SE 7 Update 21 (abril de 2013), se recomienda que los applets y las aplicaciones Web-Start estén firmados con un certificado de confianza, y aparecen mensajes de advertencia cuando se ejecutan applets no firmados. [30] Además, a partir de Java 7 Update 51, los applets no firmados fueron bloqueados de forma predeterminada; se podían ejecutar creando una excepción en el Panel de control de Java. [31]
Los límites a los subprogramas no firmados se entendieron 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 que pertenecen a paquetes básicos incluidos como parte de una versión de Java. Si bien pueden ejecutarse en un marco independiente, dicho marco contiene un encabezado que indica que se trata de un subprograma no confiable. 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.
Como sucede con cualquier sistema complejo, desde que se lanzó Java por primera vez se han descubierto y solucionado muchos problemas de seguridad. Algunos de ellos (como el error de seguridad de serialización de Calendar) persistieron durante muchos años sin que nadie se diera cuenta. Otros han sido descubiertos por malware en uso. [ cita requerida ]
Algunos estudios mencionan que los applets hacen que el navegador se bloquee o que se utilicen excesivamente los recursos de la CPU , pero estos se clasifican como molestias y no como verdaderos fallos de seguridad. Sin embargo, los applets no firmados pueden estar involucrados en ataques combinados que explotan una combinación de múltiples errores graves de configuración en otras partes del sistema. Un applet no firmado también puede ser más peligroso de ejecutar directamente en el servidor donde está alojado porque, si bien la base de código le permite comunicarse con el servidor, ejecutarlo dentro de él puede eludir el firewall. Un applet también puede intentar ataques DoS en el servidor donde está alojado, pero normalmente las personas que administran el sitio web también administran el applet, lo que hace que esto sea poco razonable. Las comunidades pueden resolver este problema mediante la revisión del código fuente o ejecutando applets en un dominio dedicado.
El subprograma no firmado también puede intentar descargar malware alojado en el servidor de origen. Sin embargo, solo puede almacenar dicho archivo en una carpeta temporal (ya que se trata de datos transitorios) y no tiene medios para completar el ataque ejecutándolo. Hubo intentos de usar subprogramas para difundir exploits de Phoenix y Siberia de esta manera, [ cita requerida ] pero estos exploits no usan Java internamente y también se distribuyeron de varias otras formas.
Un subprograma firmado [32] contiene una firma que el navegador debe verificar a través de un servidor de autoridad de certificación independiente que se ejecuta de forma remota . Producir esta firma implica 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, volviéndose equivalente a un programa independiente común. La razón es que ahora se conoce al autor del subprograma y será responsable de cualquier daño deliberado. [ vago ] Este enfoque permite que los subprogramas se utilicen para muchas tareas que de otro modo no serían posibles mediante scripts del lado del cliente. Sin embargo, este enfoque requiere más responsabilidad del usuario, que debe decidir 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 a partir de Java 1.1 pueden tener en realidad más problemas de seguridad.
Los applets autofirmados, que son applets firmados por el propio desarrollador, pueden suponer un riesgo de seguridad; los complementos de Java proporcionan una advertencia cuando solicitan autorización para un applet autofirmado, ya que la función y la seguridad del applet están garantizadas únicamente por el propio desarrollador y no han sido confirmadas de forma independiente. Estos certificados autofirmados normalmente solo se utilizan durante el desarrollo antes del lanzamiento, cuando la confirmación de seguridad por parte de terceros no es importante, pero la mayoría de los desarrolladores de applets buscarán la firma de terceros para asegurarse de que los usuarios confíen en la seguridad del applet.
Los problemas de seguridad de Java no son fundamentalmente diferentes de los problemas similares de cualquier plataforma de scripting del lado del cliente [33] [ cita requerida ] . En particular, todos los problemas relacionados con los applets firmados también se aplican a los componentes ActiveX de Microsoft .
A partir de 2014, los complementos de Java disponibles comúnmente o Java Web Start ya no aceptan applets autofirmados o no firmados. En consecuencia, los desarrolladores que desean implementar applets de Java no tienen otra alternativa que adquirir certificados confiables de fuentes comerciales.
Existen tecnologías alternativas (por ejemplo, WebAssembly [34] y JavaScript ) que satisfacen todas o más de las posibilidades que ofrece un subprograma. JavaScript podría coexistir con subprogramas en la misma página, ayudar a ejecutarlos (por ejemplo, en un marco separado o proporcionando soluciones alternativas a la plataforma) y, más tarde, ser invocado desde el código del subprograma. A medida que JavaScript ganó en características y rendimiento, el soporte y el uso de subprogramas disminuyó, hasta su eliminación final.
