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 entregan a los usuarios en forma de código de bytes de Java . El usuario inició el subprograma de Java desde una página web y, a continuación, el subprograma se ejecutó dentro de una máquina virtual Java (JVM) en un proceso separado del propio navegador web . Un applet de Java podría aparecer en un cuadro de la página Web, una nueva ventana de aplicación, Sun 's AppletViewer , o una herramienta independiente para probar los 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 el soporte para los subprogramas de tecnología subyacente que solían ejecutarse , y los subprogramas se volvieron completamente incapaces de ejecutar en 2015 –2017. Los subprogramas de Java quedaron obsoletos desde Java 9 en 2017. [6] [7] [8] [9] [10]
Los subprogramas de Java se escribían normalmente en Java, pero también se podían utilizar otros lenguajes como Jython , JRuby , Pascal , [11] Scala o Eiffel (a través de SmartEiffel ).
Los subprogramas 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 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 con un uso intensivo de la computación. Como 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), [12] [13] así como JavaScript compilado justo a tiempo , [14] la diferencia de velocidad se ha vuelto menos notorio. [ cita requerida ]
Dado que el código de bytes de Java es multiplataforma (o independiente de la plataforma), los navegadores (u otros 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 modernos que no son compatibles con Java.
Descripción general
Los subprogramas se utilizan para proporcionar funciones interactivas a aplicaciones web que no pueden proporcionarse únicamente con HTML . Pueden capturar la entrada del mouse 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 la demostración, la visualización y la enseñanza. Hay colecciones de miniaplicaciones en línea para estudiar diversos temas, desde la física hasta la 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 del navegador (mientras que también se conocen subprogramas como news tickers o editores WYSIWYG ). Los applets también pueden reproducir contenido multimedia en formatos que el navegador no admite de forma nativa.
Las páginas codificadas en HTML pueden incorporar parámetros 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 applets estaban disponibles antes de HTML5 , la moderna interfaz CSS y JavaScript DOM eran estándar, también se usaban ampliamente para efectos triviales como el mouse y los botones de navegación. Este enfoque, que planteaba importantes problemas de accesibilidad y mal uso de los recursos del sistema, ya no se utiliza y se desaconsejó rotundamente incluso en ese momento.
Información técnica
La mayoría de los navegadores ejecutan los subprogramas de Java en una caja de arena , lo que evita que los subprogramas accedan a datos locales como el portapapeles o el sistema de archivos . [ cita requerida ] El código del subprograma se descarga de un servidor web , después de lo cual el navegador integra el subprograma en una página web o abre una nueva ventana que muestra la interfaz de usuario del subprograma .
Un applet de Java se extiende la clase java.applet.Applet
, o en el caso de una oscilación applet, javax.swing.JApplet
. La clase que debe anular los métodos de la clase de subprograma para configurar una interfaz de usuario dentro de sí misma ( Applet
) es descendiente de la Panel
cual es descendiente de Container
. Dado que el subprograma hereda del contenedor, tiene en gran parte las mismas posibilidades de interfaz de usuario que una aplicación Java normal, incluidas las regiones con visualización específica del usuario.
Las primeras implementaciones consistieron en descargar un subprograma 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 .jars
se introdujeron, un subprograma generalmente se entrega como un archivo único que tiene un tamaño similar al de un archivo de imagen (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 las versiones actuales como en las futuras de la máquina virtual Java.
Tecnologías similares
Muchos desarrolladores de Java, blogs y revistas recomiendan que se utilice la tecnología Java Web Start en lugar de los subprogramas. [15] Java Web Start permite el lanzamiento de código de subprograma sin modificar, que luego se ejecuta en una ventana separada (no dentro del navegador que lo invoca).
Un Java Servlet a veces se compara informalmente con ser "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.
Incrustar en una página web
El subprograma se puede mostrar en la página web haciendo uso del applet
elemento HTML obsoleto , [16] o el object
elemento recomendado . [17] El embed
elemento se puede usar [18] con los navegadores de la familia Mozilla ( embed
fue obsoleto en HTML 4 pero está incluido en HTML 5). Esto especifica la fuente y la ubicación del subprograma. Ambas etiquetas object
y embed
también pueden descargar e instalar la máquina virtual Java (si es necesario) o al menos llevar a la página del complemento. applet
y las object
etiquetas también admiten la carga de los subprogramas serializados que comienzan en algún estado particular (en lugar de 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 object
ser oficialmente una etiqueta recomendada, a partir de 2010, el soporte de la object
etiqueta aún no era consistente entre los navegadores y Sun seguía recomendando la applet
etiqueta más antigua para implementarla en entornos de múltiples navegadores, [19] ya que seguía siendo la única etiqueta compatible de manera consistente con el navegadores más populares. Para admitir varios navegadores, la object
etiqueta actualmente requiere 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. applet
Se ha criticado la obsolescencia de la etiqueta. Oracle ahora proporciona un código JavaScript mantenido [20] para lanzar subprogramas con soluciones alternativas entre plataformas.
El complemento del navegador Java se basa en NPAPI , que muchos proveedores de navegadores web están desaprobando 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 interrumpirán el complemento del navegador. [21]
Ventajas
Un subprograma de Java puede tener cualquiera o todas las siguientes ventajas: [22]
- Es simple hacerlo funcionar en FreeBSD, Linux, Microsoft Windows y macOS, es decir, hacerlo multiplataforma. La mayoría de los navegadores web admitieron applets durante la primera década del siglo XXI; desde entonces, sin embargo, la mayoría de los navegadores han dejado de admitir subprogramas por razones de seguridad.
- El mismo subprograma puede funcionar en "todas" las versiones instaladas de Java al mismo tiempo, en lugar de sólo la última versión del complemento . Sin embargo, si un subprograma requiere una versión posterior de Java Runtime Environment (JRE), el cliente se verá obligado a esperar durante la gran descarga.
- La mayoría de los navegadores web almacenan en caché los subprogramas para que se carguen rápidamente al regresar a una página web. Los applets también mejoran con el uso: después de ejecutar un primer applet, la JVM ya se está ejecutando y se inicia rápidamente (la JVM deberá reiniciarse cada vez que el navegador se inicie de nuevo). Las versiones 1.5 y posteriores de JRE detienen la JVM y la reinician cuando el navegador navega de una página HTML que contiene un subprograma a otra que contiene un subprograma.
- Puede mover el trabajo del servidor al cliente , haciendo que una solución web sea más escalable con el número de usuarios / clientes.
- Si un programa independiente (como Google Earth ) se comunica con un servidor web, ese servidor normalmente debe admitir todas las versiones anteriores para los usuarios que no han mantenido actualizado su software cliente. Por el contrario, un navegador configurado correctamente carga (y almacena en caché) la última versión del subprograma, por lo que no es necesario admitir versiones heredadas.
- El subprograma, naturalmente, admite el cambio de estado del usuario, como las posiciones de las figuras en el tablero de ajedrez.
- Los desarrolladores pueden desarrollar y depurar un subprograma directamente simplemente creando una rutina principal (ya sea en la clase del subprograma o en una clase separada) y llamando a init () y start () en el subprograma, lo que permite el desarrollo en su entorno de desarrollo Java SE favorito. . Todo lo que uno tiene que hacer después de eso es volver a probar el subprograma en el programa AppletViewer o en un navegador web para asegurarse de que cumpla con las restricciones de seguridad.
- Un subprograma que no es de confianza no tiene acceso a la máquina local y solo puede acceder al servidor del que proviene. Esto hace que un subprograma de este tipo sea mucho más seguro de ejecutar que un ejecutable independiente que podría reemplazar. Sin embargo, un subprograma firmado puede tener acceso completo a la máquina en la que se está ejecutando si el usuario está de acuerdo.
- Los subprogramas de Java son rápidos e incluso pueden tener un rendimiento similar al del software instalado de forma nativa.
Desventajas
Un subprograma de Java puede tener cualquiera de las siguientes desventajas en comparación con otras tecnologías web del lado del cliente:
- Los subprogramas de Java dependen de un entorno de ejecución de Java (JRE), que es un paquete de software bastante complejo y pesado. También suele requerir un complemento para el navegador web. Algunas organizaciones solo permiten que un administrador instale software. Como resultado, algunos usuarios solo pueden ver los subprogramas que son lo suficientemente importantes como para justificar el contacto con el administrador para solicitar la instalación del JRE y el complemento.
- Si un subprograma requiere un JRE más nuevo que el disponible en el sistema, o un JRE específico, el usuario que lo ejecute por primera vez deberá esperar a que se complete la descarga de JRE grande.
- Los navegadores móviles en iOS o Android no ejecutan ningún subprograma de Java. [23] Los navegadores de escritorio han eliminado el soporte de subprogramas Java al mismo tiempo que el auge de los sistemas operativos móviles.
- A diferencia de la
applet
etiqueta anterior , laobject
etiqueta necesita soluciones para escribir un documento HTML en varios navegadores. - No existe un estándar para que el contenido de los subprogramas esté disponible para los lectores de pantalla. Por lo tanto, los applets pueden dañar la accesibilidad de un sitio web a usuarios con necesidades especiales.
- Al igual que con cualquier secuencia de comandos del lado del cliente, las restricciones de seguridad pueden dificultar o incluso hacer imposible que un subprograma que no sea de confianza logre los objetivos deseados. Sin embargo, simplemente editando el archivo java.policy en la instalación de JAVA JRE, se puede otorgar acceso al sistema de archivos local o al portapapeles del sistema, por ejemplo, oa otras fuentes de red distintas a la fuente de red que sirvió el subprograma al navegador.
- La mayoría de los usuarios no son lo suficientemente inteligentes como para distinguir entre subprogramas confiables y no confiables, ni les interesa aprender, por lo que esta distinción no ayudó mucho con la seguridad: demasiados usuarios ignoraron la advertencia "no confiables" cuando los navegadores estaban dispuestos a ejecutar tales subprogramas. (La capacidad de ejecutar subprogramas que no son de confianza se eliminó por completo para solucionar este problema).
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.
1997: Sun contra Microsoft
La demanda de 1997, [24] se presentó después de que Microsoft creara su propia máquina virtual Java modificada , que se envió con Internet Explorer. Microsoft agregó sobre 50 métodos y 50 campos [24] en las clases dentro de los java.awt, java.lang y java.io paquetes. 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. Se eliminó RMI porque solo admite fácilmente las comunicaciones de Java a Java y compite con la tecnología Microsoft DCOM . Los applets que se basaron en estos cambios o simplemente los usaron inadvertidamente funcionaron solo dentro del sistema Java de Microsoft. Sun presentó una demanda por violación de la 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 y Sun acordó otorgarle a Microsoft una licencia limitada para usar Java sin modificaciones únicamente y por un tiempo limitado. [25]
2002: Sun contra Microsoft
Microsoft continuó enviando su propia máquina virtual Java sin modificar. A lo largo de los años, se volvió extremadamente desactualizado, 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. [26] 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ó a Microsoft distribuir la implementación binaria actual de Sun de la tecnología Java como parte de Windows, distribuirla como una actualización recomendada para los sistemas operativos de escritorio de Microsoft más antiguos y detener la distribución de la Máquina Virtual de Microsoft (ya que su tiempo de licencia, acordado en la demanda anterior, había Caducado). [25] Microsoft pagó $ 700 millones por cuestiones antimonopolio pendientes, otros $ 900 millones por cuestiones de patentes y una tasa de regalías de $ 350 millones para utilizar el software de Sun en el futuro. [27] [se necesita fuente no primaria ]
Seguridad
Hay dos tipos de subprogramas con modelos de seguridad muy diferentes: subprogramas firmados y subprogramas sin firmar. [28] A partir de Java SE 7 Update 21 (abril de 2013), se recomienda que los subprogramas y las aplicaciones Web-Start estén firmados con un certificado de confianza, y aparecen mensajes de advertencia cuando se ejecutan subprogramas sin firmar. [29] A partir de Java 7 Update 51, los subprogramas sin firmar están bloqueados de forma predeterminada; se pueden ejecutar creando una excepción en el Panel de control de Java. [30]
No firmado
Los límites de los subprogramas sin firmar se entienden 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 al código nativo , ejecutar comandos externos en un sistema local o redefinir las clases que pertenecen a los paquetes centrales 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.
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 de Calendar) persistieron durante muchos años sin que nadie se diera cuenta. Otros han sido descubiertos en uso por malware en la naturaleza. [ cita requerida ]
Algunos estudios mencionan que los applets bloquean el navegador o hacen un uso excesivo de los recursos de la CPU , pero estos se clasifican como molestias y no como verdaderas fallas 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 hablar con el servidor, ejecutarlo dentro 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, por lo que esto no es razonable. Las comunidades pueden resolver este problema mediante la revisión del código fuente o ejecutando applets 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 medios para completar el ataque ejecutándolo. Hubo intentos de usar applets para difundir los 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.
Firmado
Un subprograma firmado [31] 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. El motivo 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 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 los editores de subprogramas conocidos que aún hacen algo que el usuario no aprobaría. Por lo tanto, los subprogramas firmados que aparecieron a partir de Java 1.1 pueden tener más problemas de seguridad.
Autofirmado
Los subprogramas autofirmados, que son subprogramas firmados por el propio desarrollador, pueden suponer un riesgo de seguridad; Los complementos de Java proporcionan una advertencia cuando se solicita autorización para un subprograma autofirmado, ya que la función y la seguridad del subprograma están garantizadas solo por el propio desarrollador y no se ha confirmado de forma independiente. Dichos certificados autofirmados generalmente solo se usan durante el desarrollo antes del lanzamiento cuando la confirmación de seguridad 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 [32] [ cita requerida ] . 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 subprogramas autofirmados y sin firmar ya no son aceptados por los complementos de Java comúnmente disponibles o Java Web Start. 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 [33] y JavaScript ) que satisfacen todo o más del alcance de lo que es posible con un applet. JavaScript puede coexistir con subprogramas en la misma página, ayudar a iniciar subprogramas (por ejemplo, en un marco separado o proporcionar soluciones alternativas de la plataforma) y luego ser llamado desde el código del subprograma. JavaFX es una extensión de la plataforma Java y también puede verse como una alternativa.
Ver también
- ActiveX
- Curl (lenguaje de programación)
- Servlet de Yakarta
- Inicio de Java Web
- JavaFX
- Aplicación web enriquecida
- WebGL
Referencias
- ^ "El sitio de inicio del visor de proteínas 3D (Openastexviewer) bajo LGPL" . Archivado desde el original el 1 de agosto de 2009 . Consultado el 21 de septiembre de 2009 .
- ^ "El hogar virtual" .
- ^ "El sitio de inicio del applet de conjunto de Mandelbrot bajo GPL" . Archivado desde el original el 8 de mayo de 2013 . Consultado el 29 de julio de 2013 .
- ^ "El sitio de inicio del subprograma de ajedrez bajo BSD" . Archivado desde el original el 7 de septiembre de 2009.
- ^ "Java.Sun.com" .
- ^ "Notas de la versión de Java 9" .
- ^ "JEP 289: Desaprovechar la API de Applet" .
- ^ "Blog JPG: Pasando a una Web sin complementos" .
- ^ "Blog de JPG: nuevas actualizaciones de 'Migrar a una Web sin complementos ' " .
- ^ http://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf
- ^ "Compilador Pascal libre para JVM" .
- ^ "lienzo - HTML" . Red de desarrolladores de Mozilla . Consultado el 15 de agosto de 2015 .
- ^ "WebGL - Interfaces API web" . Red de desarrolladores de Mozilla . Consultado el 15 de agosto de 2015 .
- ^ "Elementos de diseño: Chrome V8" . Consultado el 15 de agosto de 2015 .
- ^ Srinivas, Raghavan N. (6 de julio de 2001). "Java Web Start al rescate" . JavaWorld . Consultado el 13 de julio de 2020 .
- ^ "W3.org" .
- ^ "W3.org" .
- ^ "Descargas de Java para todos los sistemas operativos" . Java.com. 14 de agosto de 2012 . Consultado el 14 de junio de 2013 .
- ^ "Posición del sol en etiquetas de objeto y subprograma" . Archivado desde el original el 9 de junio de 2010 . Consultado el 14 de enero de 2010 .
- ^ Lanzador de subprogramas Java de Oracle - ¡Enlace roto! [ enlace muerto permanente ]
- ^ "Oracle desaprueba el complemento del navegador Java, se prepara para su desaparición" . Ars Technica . Consultado el 15 de abril de 2016 .
- ^ Descripción general oficial de Oracle sobre la tecnología de subprogramas Java
- ^ "¿Cómo obtengo Java para dispositivos móviles?" . 30 de julio de 2014.
- ^ a b Zukowski, John (1 de octubre de 1997). "¿Qué significa la demanda de Sun contra Microsoft para los desarrolladores de Java?" . JavaWorld . Consultado el 13 de julio de 2020 .
- ^ a b "Página de Sun, dedicada a los juicios contra Microsoft" .[ enlace muerto permanente ]
- ^ Kenai.com (2011) Archivado el 23 de agosto de 2011 en Wayback Machine. Los problemas más comunes se encuentran en el código de los subprogramas revisados.
- ^ Página de Microsoft dedicada al Sun - Demanda de Microsoft 2002 Archivada el 25 de febrero de 2010 en Wayback Machine
- ^ "Explicación de Sun sobre la seguridad del subprograma" .
- ^ "Java Applet & Web Start - Firma de código" . Oracle . Consultado el 28 de febrero de 2014 .
- ^ "¿Qué debo hacer cuando veo un mensaje de seguridad de Java?" . Oracle . Consultado el 28 de febrero de 2014 .
- ^ "Informit.com" .
- ^ "Para ser justos, muchos más usuarios de la World Wide Web utilizan el producto Netscape que el producto de Microsoft en la actualidad, aunque la brecha parece estar cerrándose" . www.wiley.com . Consultado el 17 de marzo de 2017 .
- ^ "Mozilla intenta hacer Java como debería haber sido, con una especificación WASI para todos los dispositivos, computadoras y sistemas operativos" . www.theregister.com . Consultado el 6 de octubre de 2020 .
enlaces externos
- Última versión de la máquina virtual Java de Sun Microsystems (incluye complementos del navegador para ejecutar subprogramas Java en la mayoría de los navegadores web).
- Información sobre la escritura de subprogramas de Oracle
- Applets de demostración de Sun Microsystems ( JDK 1.4 - incluye código fuente)