Los subprogramas de Java eran pequeñas aplicaciones escritas en el lenguaje de programación Java u otro lenguaje de programación que se compila en 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 subprograma de Java desde una página web y luego el subprograma se ejecutaba dentro de una máquina virtual Java (JVM) en un proceso independiente del propio navegador web . Un subprograma de Java podría aparecer en un marco de la página web, en una nueva ventana de la aplicación, en un programa de Sun llamado appletviewer [6] o en una herramienta independiente para probar subprogramas. [ se necesita aclaración ]
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 el soporte para la tecnología subyacente que los subprogramas usaban para ejecutarse , y en 2015 los subprogramas dejaron de poder ejecutarse por completo. –2017. Los subprogramas de Java quedaron obsoletos con Java 9 en 2017. [7] [8] [9] [10] [11]
Los subprogramas de Java generalmente se escribían en Java, pero también se podían usar otros lenguajes como Jython , JRuby , Pascal , [12] Scala , NetRexx o Eiffel (a través de SmartEiffel ).
Los subprogramas de Java se ejecutan a velocidades muy rápidas [ cita necesaria ] y hasta 2011, eran muchas veces más rápidos que JavaScript . [ cita necesaria ] A diferencia de JavaScript, los subprogramas de Java tenían acceso a la aceleración de hardware 3D , lo que los hacía muy adecuados para visualizaciones no triviales y que requieren un uso intensivo de computación. 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 JavaScript compilado justo a tiempo , [15] la diferencia de velocidad se ha vuelto menos notorio. [ cita necesaria ]
Dado que el código de bytes de Java es multiplataforma (o independiente de la plataforma), los clientes pueden ejecutar subprogramas 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 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 aplicaciones web que HTML no puede proporcionar únicamente. 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 demostración, visualización y enseñanza. Hay colecciones de subprogramas en línea para estudiar diversos temas, desde física hasta fisiología del corazón.
Un subprograma también puede ser sólo 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 (aunque también se conocen subprogramas como los tickers de noticias o los editores WYSIWYG ). Los applets también pueden reproducir medios en formatos que el navegador no admite de forma nativa.
Las páginas codificadas en HTML pueden incrustar parámetros dentro de ellas que se pasan al subprograma. Debido a esto, el mismo subprograma puede tener una apariencia diferente dependiendo de los parámetros que se pasaron.
Como los subprogramas estaban disponibles antes de HTML5 , la interfaz DOM moderna de CSS y JavaScript eran estándar, también se usaban ampliamente para efectos triviales como botones de navegación y mouseover . Este enfoque, que planteaba importantes problemas de accesibilidad y mal uso de los recursos del sistema, ya no se utiliza y fue desaconsejado enérgicamente incluso en su momento.
La mayoría de los navegadores ejecutaban subprogramas Java en un entorno limitado , impidiendo que los subprogramas accedieran a datos locales como el sistema de archivos . [16] 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 implicaron descargar un subprograma clase por clase. Si bien las clases son archivos pequeños, a menudo hay muchos, por lo que los applets adquirieron la reputación de ser componentes de carga lenta. Sin embargo, desde que .jarse introdujeron los archivos, un subprograma generalmente se entrega como un solo archivo que tiene un tamaño similar al de un archivo de imagen (de cientos de kilobytes a varios megabytes).
Las bibliotecas y los 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.
Muchos desarrolladores, blogs y revistas de Java recomendaron que se utilizara la tecnología Java Web Start en lugar de subprogramas. [17] Java Web Start permitía el lanzamiento de código de subprograma no modificado, que luego se ejecutaba en una ventana separada (no dentro del navegador que lo invocaba).
Un Servlet Java a veces 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.
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 utilizar [20] con los navegadores de la familia Mozilla ( embedquedó obsoleto en HTML 4 pero está incluido en HTML 5). Esto especifica el origen y la ubicación del subprograma. Ambas etiquetas objecty embedtambién pueden descargar e instalar la máquina virtual Java (si es necesario) o al menos conducir a la página del complemento. applety objectlas etiquetas también admiten la carga de subprogramas 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 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 su implementación en entornos de múltiples navegadores, [21] ya que seguía siendo la única etiqueta soportada consistentemente por los navegadores más populares. navegadores. Para admitir múltiples 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 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 ejecución de Java basados en JDK 9 descontinuarán el complemento del navegador. [22]
Un subprograma de Java podría tener alguna o todas las siguientes ventajas: [23]
Los subprogramas de Java tenían las siguientes desventajas en comparación con otras tecnologías web del lado del cliente:
Sun hizo esfuerzos considerables para garantizar que se mantenga la compatibilidad entre las versiones de Java a medida que evolucionan, imponiendo la portabilidad de Java por ley si es necesario. Oracle parece continuar con la misma estrategia.
La demanda de 1997, [25] se presentó después de que Microsoft creara su propia máquina virtual Java modificada , que se entregaba con Internet Explorer. Microsoft agregó alrededor de 50 métodos y 50 campos [25] 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 Java a Java y compite con la tecnología DCOM de Microsoft . Los applets que se basaron en estos cambios o simplemente los usaron sin darse cuenta funcionaron sólo dentro del sistema Java de Microsoft. Sun presentó una demanda 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 de dólares, y Sun acordó otorgarle a Microsoft una licencia limitada para usar Java únicamente sin modificaciones y por un tiempo limitado. [26]
Microsoft continuó enviando su propia máquina virtual Java sin modificaciones. Con el paso de los años, se volvió extremadamente obsoleto y aún así sigue siendo el predeterminado para Internet Explorer. Un estudio posterior reveló que los subprogramas de esta época a menudo contienen sus propias clases que reflejan Swing y otras características más nuevas de manera limitada. [27] En 2002, Sun presentó una demanda antimonopolio , alegando que los intentos de Microsoft de monopolizar ilegalmente 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 de Microsoft más antiguos y que detuviera la distribución de la Máquina Virtual de Microsoft (ya que el plazo de la licencia, acordado en la demanda anterior, había sido venció). [26] Microsoft pagó 700 millones de dólares por cuestiones antimonopolio pendientes, otros 900 millones de dólares por cuestiones de patentes y una tarifa de regalías de 350 millones de dólares para utilizar el software de Sun en el futuro. [28] [ se necesita fuente no primaria ]
Había dos tipos de subprogramas con modelos de seguridad muy diferentes: subprogramas firmados y subprogramas sin firmar. [29] A partir de Java SE 7 Actualización 21 (abril de 2013), se recomienda que los subprogramas y las aplicaciones Web-Start estén firmados con un certificado confiable, y aparecen mensajes de advertencia cuando se ejecutan subprogramas sin firmar. [30] Además, a partir de la actualización 51 de Java 7, los subprogramas sin firmar se bloquearon de forma predeterminada; podrían ejecutarse creando una excepción en el Panel de control de Java. [31]
Los límites de los subprogramas no firmados se entendieron como "draconianos": no tienen acceso al sistema de archivos local y el acceso web se limita al sitio de descarga del subprograma; También existen 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 principales 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 que no es de confianza. La llamada inicial exitosa al 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 proviene de una ubicación incorrecta.
Como ocurre 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 se diera cuenta. Otros han sido descubiertos en uso por malware en la naturaleza. [ cita necesaria ]
Algunos estudios mencionan que los subprogramas bloquean el navegador o hacen un uso excesivo de los recursos de la CPU , pero se clasifican como molestias y no como verdaderos fallos de seguridad. Sin embargo, los subprogramas sin firmar 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 sin firmar 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 dentro de él puede evitar el firewall. Un subprograma 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 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, sólo puede almacenar dicho archivo en una carpeta temporal (ya que son datos transitorios) y no tiene medios para completar el ataque ejecutándolo. Hubo intentos de utilizar subprogramas para difundir los exploits de Phoenix y Siberia de esta manera, [ cita necesaria ] pero estos exploits no utilizan Java internamente y también se distribuyeron de 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 . La producción de 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, 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. [ vago ] 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 una mayor responsabilidad por parte del usuario, al 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 en realidad pueden tener más problemas de seguridad.
Los subprogramas autofirmados, que son subprogramas firmados por el propio desarrollador, pueden suponer un riesgo de seguridad; Los complementos de Java proporcionan una advertencia al solicitar autorización para un subprograma autofirmado, ya que la función y la seguridad del subprograma están garantizadas únicamente por el propio desarrollador y no han sido confirmadas de forma independiente. Estos certificados autofirmados generalmente solo se usan 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 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 problemas similares de cualquier plataforma de scripting del lado del cliente [33] [ cita necesaria ] . En particular, todas las cuestiones relacionadas con los subprogramas firmados también se aplican a los componentes de Microsoft ActiveX .
A partir de 2014, los complementos Java comúnmente disponibles o Java Web Start ya no aceptan subprogramas autofirmados y no firmados. En consecuencia, los desarrolladores que deseen implementar subprogramas 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 todo o más del alcance de lo que era posible con un subprograma. JavaScript podría coexistir con subprogramas en la misma página, ayudar a iniciar subprogramas (por ejemplo, en un marco separado o proporcionar soluciones alternativas a la plataforma) y luego ser invocado desde el código del subprograma. A medida que JavaScript ganó en características y rendimiento, el soporte y el uso de applets disminuyeron, hasta su eventual eliminación.
