IMPLMENTACIONES LIBRES DE J2SE: ESTADO ACTUAL A. Otero1, A. Sánchez-Mariscal2 1Departamento de Ingeniería del Software y del Conocimiento, Universidad San Pablo CEU, España 2 javaHispano, http://javahispano.org, España [email protected] En este trabajo se estudia el estado actual de las especificaciones relacionadas con J2EE y diferentes proyectos libres que permiten ejecutar J2SE (ediciones empresarial y estándar, aplicaciones Java sin depender de software respectivamente, de la plataforma), y el otro de propietario. Sólo se han tenido en cuenta los las relacionadas con J2ME (edición para proyectos que en la actualidad muestran una pequeños dispositivos). Convertirse en miembro actividad alta y han obtenido logros considerables, tomando como baremo de dichos logros las del JCP es gratis para empresas licenciatarias de aplicaciones Java que han sido capaces de compilar Sun (empresas que implementan y/o ejecutar. especificaciones de la plataforma con ánimo de lucro y pagan por ello a Sun), y para personas El trabajo pretende servir de apoyo y guía a que a título individual deseen formar parte del aquellas organizaciones o individuos interesados en encontrar soluciones que permitan ejecutar en un JCP. Las empresas no licenciatarias han de entorno completamente libre aplicaciones escritas pagar 5000 $ por año. En el caso de en lenguaje Java. organizaciones sin ánimo de lucro e instituciones académicas, un comité decide si pueden formar parte del JCP gratis, o han de Introducción pagar 2000 $. Cualquier miembro del JCP Individuos, pequeños grupos de usuarios de (incluso los individuos) es elegible para los CE. Linux, universidades, empresas e incluso instituciones gubernamentales han acudido en Las incorporaciones de nuevas tecnologías a la alguna ocasión a javaHispano para consultar si plataforma Java se realizan a través del JCP, "¿Java es libre?". Irónicamente, a ninguno de mediante un JSR, Java Specification Request ellos le interesaba la respuesta a esa pregunta, a (3), un documento que explica la necesidad de la cual se ha tratado de responder en (1). La esa nueva tecnología, o de modificación de una pregunta que pretendían formular es "¿Existe tecnología ya existente, y cómo afectará este alguna implementación libre del entorno base de cambio al resto de la plataforma. Cualquiera, la plataforma Java?". Para entender la diferencia sea o no miembro del JCP, puede proponer entre ambas preguntas es necesario conocer qué nuevos JSR. Uno de los dos CE del JCP, según es la plataforma Java. Ésta está formada por un el nuevo JSR afecte a J2ME, o a J2SE/J2EE, conjunto de especificaciones que definen todas analiza la propuesta y decide si acepta o no la y cada una de sus partes, y una serie de creación del JSR y, posteriormente, si se implementaciones de estas especificaciones. aprueba o no. Estas decisiones se realizan mediante una votación pública. Para completar El JCP, Java Community Process, es el un JSR también se debe desarrollar una organismo que dirige, mediante la creación de implementación de referencia de la nuevas especificaciones y el mantenimiento de especificación y una batería de pruebas que las ya existentes, la evolución de la plataforma. permitan verificar si una implementación de un Este organismo define su propio tercero sigue o no la especificación. No hay funcionamiento y las normas por las que se rige; impedimentos para que terceras partes creen las vigentes actualmente se recogen en (2). otras implementaciones bajo cualquier licencia y sin pagar royalties. El JCP consta de dos Comités Ejecutivos (CE), cada uno de ellos compuesto por 16 miembros, Por tanto, Java más que un software es un que se encargan de aprobar las modificaciones y estándar (especificación), y preguntarse si Java extensiones de la plataforma; uno se encarga de es libre equivale a preguntarse si Java puede considerarse un estándar libre. Según los para aplicaciones reales. En las versiones más propios criterios del mundo del software libre, recientes, 4.X, el soporte para AWT está la respuesta a esta pregunta es afirmativa (1). prácticamente completo y el soporte para Swing (objetivo del proyecto Free Swing) está muy En ese trabajo se trata de dar respuesta a la avanzado, pero aún no es suficiente para pregunta ¿Existe alguna implementación libre aplicaciones reales. del entorno base de la plataforma?. Para ello se analiza de modo breve, pero exhaustivo dentro Uno de los motivos del éxito de Java son sus de las posibilidades de los autores, las extensas y completas librerías; un compilador o implementaciones libres del entorno base de la un intérprete Java sin una implementación de plataforma Java (J2SE) o de alguna de sus las librerías base sólo permitirá trabajar con partes principales (compilador, máquina virtual pequeños programas juguete sin ningún interés o librerías estándar). Sólo se han estudiado práctico. Las librerías que incorpora libgcj en la aquellas implementaciones que permiten actualidad son una adaptación de GNU ejecutar aplicaciones Java de cierta Classpath (5). Este proyecto inicialmente fue envergadura, por considerar que son las más diseñado para trabajar con la máquina virtual maduras y útiles. El realizar un estudio que Japhar, una de las primeras máquinas virtuales abarque todas las implementaciones existentes libres que se desarrollaron que en la actualidad desborda los límites de espacio de este trabajo: está completamente abandonada y cuyo soporte existen, al menos, unas dos docenas. para Java se encuentra muy desfasado. Classpath constituye el pilar central de cualquier A continuación se presenta, por este orden, el implementación funcional actual del JDK, ya estado actual de GCJ, Kaffe, IKVM y JNode. que todas se basan en él. También suele ser el Junto con GCJ también se analizará el estado de factor limitante en lo relativo a compatibilidad Classpath, una implementación de las librerías con la especificación de una determinada Java que comparten los cuatro proyectos. alternativa. Además de las soluciones que se Finalmente, se discute hasta qué punto es viable recogen en este documento, estas librerías son o ejecutar aplicaciones Java en un entorno han sido empleadas por JAmiga, Jaos, JamVM, completamente libre y se presentan las JC, Jikes, Júpiter, Kissme, SableVM, CACAO y conclusiones extraídas de este trabajo. ORP, entre otras. Classpath puede considerarse 100% compatible GCJ + Classpath con las librerías de los JDKs 1.0 y 1.1, versiones La FSF comenzó su que actualmente son demasiado antiguas para implementación del resultar de interés en desarrollos reales. El entorno base de la soporte de Swing puede considerarse la única plataforma Java en la falla en la compatibilidad respecto a los JDKs segunda mitad de 1998. 1.2 y 1.3, versiones que, aunque un poco Esta implementación, desfasadas, sí se emplean todavía en entornos de con nombre GCJ (4), se integra dentro GCC y producción. La compatibilidad con el JDK 1.4, su objetivo es proporcionar soporte para Java sin considerar Swing, no es completa aunque dentro de la colección de compiladores. está bastante cercana. A principios de enero del 2006 la rama de Classpath que incluye soporte GCJ permite compilar código Java a código para tipos genéricos (la más completa) carecía máquina, bytecode a código máquina y código de 2 paquetes, 54 clases, 85 métodos y 11 Java a bytecode. Las aplicaciones compiladas constructores de las librerías estándar del JDK son enlazadas con el entorno de ejecución de 1.4; y contenía 5 clases, 2 campos y 1 GCJ, libgcj (4), que proporciona las librerías constructor implementados de modo incorrecto estándar Java, un colector de basura y un (6). La compatibilidad con el JDK 1.5, a nivel intérprete de bytecode. libgcj da soporte a una de librerías, deja bastante que desear: faltan 22 gran parte de las librerías estándar de Java, entre paquetes, 118 clases, 15 interfaces, 8 ellas el framework de colecciones, java.net, enumeraciones, 57 campos, 396 métodos y 66 java.io, java.lang, reflexión, y serialización. En constructores; y 13 clases, 4 campos, 4 métodos las versiones 3.X existía una gran cantidad de y 3 constructores están implementados de modo código AWT, sin embargo no era suficiente incorrecto (6). Estos datos fueron obtenidos mediante las bien la única de la cual existen archivos herramientas japitools, Java API compatibility liberados es gjdoc, equivalente a la herramienta testing tools (6). japitools consta de dos javadoc del JDK de Sun. herramientas que permiten testar la compatibilidad de las librerías Java contra la GCJ soporta applets mediante un proyecto implementación de Sun, así como la externo, gcjwebplugin, del cual aún no existe compatibilidad hacia atrás entre dos versiones ninguna versión estable. Sin embargo, este cualesquiera de las librerías. Las herramientas proyecto no tiene implementado ningún gestor son japize y japicompat. Japize es un programa de seguridad, por lo que los applets y Java que crea un listado a partir de una API Java aplicaciones JNLP tienen acceso ilimitado a los en un formato no legible por un ser humano. recursos de la máquina, y no soporta todos los Japicompat toma como entrada dos de estos navegadores web. listados y compara su compatibilidad binaria según lo definido en la especificación del GCJ da soporte a la depuración de aplicaciones lenguaje Java (7). japitools no está preparada mediante la herramienta gdb, pero no para tener en cuenta aspectos del API que usen implementa el protocolo JDWP (Java Debug las nuevas características de Java 1.5, por lo que Wire Protocol). El soporte de este protocolo es realiza la comparación basándose en la opcional: una implementación puede ser Java semántica de los binarios de Java 1.4. Ambas compatible sin soportarlo. Sin embargo, es herramientas se ejecutan diariamente contra el empleado por la mayor parte de los IDEs y el no CVS de Classpath. implementarlo impide la integración de GCJ con ellos. En el futuro, se pretende añadir Hasta hace un par de años libgcj proporcionaba soporte para JDWP en Classpath.