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 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, , 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 (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 (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, , 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, 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. informes de su compatibilidad a nivel de librerías con los JDKs de Sun empleando Respecto a la licencia bajo la cual se distribuye japitools. En la actualidad han cesado de GCJ, como es de esperar, es GPL 2.0, a proporcionarlos, pero esta debe ser muy similar excepción de libgcj (y Classpath) que se a la de Classpath. Sí existe información acerca distribuyen bajo la licencia GPL 2.0 con la de la compatibilidad entre libgcj y Classpath, "excepción libgcc". Esta excepción permite pero el último informe data de diciembre de enlazar código con la librería sin que éste quede 2004 y es de esperar que en la actualidad estén bajo el efecto de la licencia GPL. mucho más próximos. Kaffe Respecto al soporte del lenguaje, GCJ no soporta las nuevas características de Java 1.5. Kaffe (9) Éstas se están desarrollando en GCJX, que se fue uno de convertirá en el nuevo compilador Java de los GCC. Actualmente GCJX es capaz de parsear y primeros analizar código Java 1.4 correctamente, y posee intentos para conseguir un JDK libre. Su un soporte bastante amplio de las nuevas desarrollo comenzó en 1996 y fue respaldado características de Java 1.5, si bien en este último por la desaparecida compañía Transvirtual caso todavía tiene bastantes bugs y el soporte Technologies. El principal producto de esta para tipos genéricos no está terminado. compañía, donante de una considerable cantidad Actualmente GCJX es capaz de compilar la de código y tiempo de sus desarrolladores para versión de Classpath que incluye tipos genéricos el proyecto, era una máquina virtual comercial con un poco de trabajo manual. propietaria, KaffePro, que compartía código con la libre. En 1998 Kaffe llegó a ganar el premio GCJ carece de herramientas para la gestión de de JavaWorld a la mejor máquina virtual. certificados (keytool), para firmar archivos jar (jarsigner), herramientas de apoyo al desarrollo Este proyecto sufrió dos golpes bastante duros. de aplicaciones RMI (rmic y rmiregistry) y Primero su fundador, Tim Wilkinson, dejó de corba, así como herramientas similares a javap, trabajar para Transvirtual y de tener tiempo para javah, serialver, native2ascii... Algunas de estas Kaffe. El proyecto estuvo casi parado durante herramientas se están desarrollando actualmente un período de dos años comprendido entre 2000 bajo el proyecto GNU Classpath::Tools (8), si y 2002 en el que no se liberó ningún archivo. En 2002 Jim Pick tomó el relevo a Tim tanto al soporta JDWP, por lo que no puede ser frente de Kaffe como de KaffePro, siendo el integrado con IDEs. Su licencia es GPL. líder actual del proyecto. Ese mismo año quebró Transvirtual Technologies y, por tanto, cesaron las contribuciones de código y desarrolladores a IKVM Kaffe. IKVM (12) es A pesar de estas desventuras y de haber pasado una por un tiempo de baja actividad, el proyecto ha imple- logrado remontar vuelo. Actualmente libera mentación de Java para Microsoft .NET y revisiones con más frecuencia que GCJ y Mono, implementación libre de la plataforma SouJava cree que Kaffe junto con Classpath .NET desarrollada por Miguel de Icaza y constituirán la primera implementación libre del apoyada por Novell. Obviamente, para los entorno base de la plataforma Java (10); para objetivos de este artículo, nuestro interés se trabajar en la línea de la obtención de la centra en la segunda plataforma. IKVM consta certificación de esta implementación han creado de una máquina virtual Java implementada en el proyecto roxo (11). .NET, de una implementación de las librerías estándar de Java en .NET y de un conjunto de Kaffe es una máquina virtual tradicional basada herramientas para permitir la interoperabilidad en intérprete y compilador JIT (Just In Time). entre java y .NET. Aunque inicialmente contaba con su propia implementación de las librerías estándar, ésta se IKVM permite ejecutar aplicaciones Java de dos quedó desfasada y se ha ido fusionando poco a modos diferentes. El primero emplea una poco con Classpath; en la actualidad el soporte máquina virtual que interpreta el bytecode y lo de Kaffe a nivel de librerías puede considerarse transforma a IL (Intermediate Language) de idéntico al del proyecto GNU. Existen planes .NET, el cual es a su vez interpretado por el para que en el futuro la máquina virtual entorno de ejecución de la segunda plataforma. funcione directamente sobre Classpath sin El segundo traduce de modo "estático" el necesidad de realizar ninguna adaptación. bytecode a IL de .NET, el cual es interpretado directamente por el entorno de ejecución. La principal carencia de este proyecto es la casi total ausencia de documentación. El equipo de En ambos casos IKVM parte de bytecode Java, desarrolladores parece haberse olvidado no disponiendo de herramientas que permitan completamente de este tema: en su portal ni compilar el código fuente. Por tanto, con vistas siquiera proporcionan información sobre qué a conseguir un entorno base completo libre de la características del lenguaje soporta y cuál es el plataforma Java, IKVM necesita de un estado de desarrollo de las no soportadas. Los compilador libre. También deja abierto el comentarios que acompañan a cada nueva problema de la depuración del código fuente versión son breves y parcos en detalles. Las Java, así como las herramientas de apoyo al listas de correo públicas y un FAQ bastante desarrollo (javadoc, jarsigner, javap...). desfasado son la única documentación existente. Desgraciadamente, Kaffe constituye un Al igual que Kaffe y GCJ, IKVM se basa en excelente "caso de uso" para una de las críticas Classpath para obtener las librerías estándar, más comunes a los proyectos libres: la falta de aunque debe añadir a éstas cierto código documentación. específico. Parte de este código son los peers de AWT para .NET, desarrollo que actualmente no Kaffe ha permitido ejecutar 3.1 y 3.0, constituye una prioridad para el proyecto. Por Tomcat 3.X, 4.X y 5.X, JBoss 3.2, Resin, tanto, en lo relativo a soporte de librerías IKVM HSQLDB, Berkeley DB, Prevayler, SwingWT, se encuentra por debajo de los anteriores. En lo Ant, Rhino, múltiple drivers JDBC y varios de referente al lenguaje, IKVM soporta los proyectos de Apache Jakarta. El proyecto completamente Java 1.4, aunque no 1.5. también tiene un conjunto de herramientas de apoyo al desarrollo similares a javap, serialver, Este proyecto podría permitir escribir rmic, rmiregistry, javadoc... aunque, al igual programas con sintaxis Java empleando las que el resto del proyecto, sin documentar. No librerías de Mono, supliendo así las deficiencias de Classpath. De este modo se podrían construir Discusión programas que se ejecutasen en un entorno completamente libre, aunque quedaría por El principal factor limitante en la resolver la parte de compilación. compatibilidad de todas las implementaciones son las librerías, en especial el soporte de Algunas aplicaciones que han sido ejecutadas Swing, imprescindible para obtener un JDK 1.2 con éxito con IKVM son Eclipse, y compatible o superior. En este sentido, cabe JBoss. La licencia de IKVM es tipo Apache, destacar el espíritu de cooperación de la aunque para funcionar necesita de Classpath, comunidad del software libre que, viendo lo con el que se puede enlazar debido la excepción ardua que era la tarea, abandonó las múltiples libgc. implementaciones paralelas para cerrar filas entorno a Classpath.

JNode Quizás alguien podría pensar que, como JNode, Java solución transitoria, podría emplearse un New Operating compilador y una máquina virtual libres contra System Design las librerías de Sun. Esto no es posible ni Effort (13), es un técnica ni legalmente. La imposibilidad legal proyecto con surge de la licencia bajo la cual se distribuyen licencia LGPL cuyo objetivo es construir un dichas librerías. La técnica, es que estas sistema operativo fácil de instalar y usar que librerías realizan múltiples llamadas a métodos permita ejecutar de modo seguro cualquier nativos no documentados que implementa la aplicación Java. Los orígenes del proyecto se máquina virtual de Sun. Intentar emplear las remontan a 1996. Por aquel entonces Ewout librerías con otra máquina virtual supondría Prangsma, fundador del proyecto, se planteó el implementar en ella esos métodos no reto de construir no sólo una máquina virtual documentados cuya funcionalidad se conoce. Java, sino un sistema operativo completo. Tras Aunque se han obtenido importantes logros dos intentos fallidos en los que se empleó y ejecutando aplicaciones de envergadura, sobre ensamblador nació JNode, programado en Java todo con Kaffe y GCJ, también hay que y con una cantidad mínima de ensamblador. En reconocer que el ejecutar estas aplicaciones la actualidad JNode es funcional y soporta una requiere, habitualmente, de bastante trabajo gran parte del hardware más común para PCs. manual y artimañas que se escapan a las JNode depende de Classpath para obtener las capacidades de un usuario medio. Uno de los librerías estándar de Java. En lo que destaca el ejemplos más conocidos es el trabajo realizado proyecto es en el soporte del lenguaje: en la por Debian y otras distribuciones para conseguir actualidad soporta todas las nuevas que funcionase OpenOffice.org 2.0. características de Java 1.5. No obstante, debe Hay dos impedimentos principales a la hora de resaltarse que el objetivo de JNode es sólo ejecutar un código fuente Java con software proporcionar un entorno de ejecución para libre. El primero, el soporte de Swing. La aplicaciones Java, por lo que no han tenido que solución pasa por emplear otras alternativas desarrollar un compilador para Java 1.5, sino como AWT o SWT; de todos modos, ha habido solamente un intérprete tipo JIT. ciertos casos de éxito en la compilación de De modo similar a IKVM, JNode resuelve el aplicaciones que usan Swing. El segundo problema de ejecutar aplicaciones Java impedimento son las dependencias del código empleando sólo software libre, aunque con un fuente con paquetes com.*; estos paquetes mayor soporte para el lenguaje (soporte que pertenecen al JDK de Sun pero no forman parte puede considerarse completo) y mejor soporte de las librerías estándar. Es curioso que esta sea para las librerías, ya que se encuentra al mismo una de las causas de los fracasos a la hora de nivel que Classpath y no por debajo de éste. llevar aplicaciones Java a una plataforma libre, Nuevamente, queda por resolver la compilación sobre todo cuando el propio Sun recomienda no y el proporcionar herramientas de apoyo al emplear dichos paquetes ya que pueden cambiar desarrollo. en el futuro y emplearlos rompe la portabilidad entre distintas implementaciones del entorno base. Sin embargo, esta es la causa de muchos versión 2.6 del JCP; esto es, sólo podría fracasos de GCJ y Kaffe. certificarse un JDK compatible con Java 1.5.

En la actualidad, tanto la implementación de El soporte para Java 1.4, excluyendo Swing, es Kaffe como la de GCJ dedican la mayor parte relativamente alto. En el caso de Java 1.5, de esfuerzos a desarrollar un entorno de última versión de la plataforma que ha ejecución, que no un JDK completo. Esto viene introducido un número considerable de motivado por conseguir entornos de ejecución cambios, deja bastante que desear. completamente libres para poder ejecutar software libre escrito en Java en las No obstante, se ha demostrado que es posible distribuciones de Linux. Si bien el fin es loable, compilar aplicaciones a código nativo (GCJ) y no lo es tanto una de sus consecuencias: la falta ejecutarlas en una máquina virtual tradicional casi total de herramientas libres para el (Kaffe) empleando única y exclusivamente desarrollo de aplicaciones Java. Si ejecutar software libre: Eclipse, OpenOffice.org, JOnAS, aplicaciones Java en un entorno completamente JBoss, Tomcat, Resin y Ant han sido los libre es complicado, el desarrollarlas es principales logros hasta la fecha. imposible o extremadamente complejo. Aun a riesgo de ser tachados de optimistas, En el estudio no se ha incluido Harmony, una creemos que estamos a no mucho más de un par implementación desarrollada por Apache de años de tener una implementación completa Software Foundation, por no disponer en la funcional de Java 1.5, que podría ser Kaffe + actualidad de ninguna solución funcional. No Classpath, GCJ + Classpath o Harmony. obstante, es un proyecto con grandes posibilidades de éxito que no se debe perder de vista. Aunque no podrá reutilizar ningún trabajo Palabras clave: Java, GCJ + Classpath, Kaffe, de los anteriores, ya que se distribuyen bajo IKVM. licencias incompatibles con la de Apache (GPL o LGPL), podría completar una implementación de Java 1.5 a medio plazo. Por un lado, el Bibliografía: proyecto cuenta con el apoyo de una comunidad (1) A Otero, "Estándares libres y Java: ¿Es el tan activa y numerosa como la de Apache. Por JPC un organismo que crea estándares libres?. II otro, la excelente relación que la fundación Congreso javaHispano, páginas 87-98. Madrid, mantiene con múltiples empresas y el hecho de 2004. que el código fuente del proyecto podría (2) JCP v. 2.6. http://jcp.org/aboutJava utilizarse en productos comerciales augura un /communityprocess/first/jsr215/JCP2_6.pdf. notable apoyo empresarial. Hasta la fecha, Intel ya ha contribuido con código para temas (3) Java Specification Request. relacionados con criptografía y seguridad, e http://www.jcp.org/ en/jsr/overview. IBM ha donado los paquetes java.lang, java.util, (4) GCJ. Http://gcc.gnu.org/java. java.io y java.net, así como una interfaz que (5) Classpath. http://www.classpath.org. permitirá emplear las librerías de Harmony con cualquier máquina virtual. (6) Japitools. http://www.kaffe.org/~stuart/japi. (7) J. Gosling, B. Joy, G. Steele, G. Bracha. The Java Language Specification. Addison Wesley, Conclusiones 2003. Actualmente sólo se podría conseguir una (8)Classpath::Tools. implementación completa del entorno base de la http://www.gnu.org/software/classpath/cp-tools. plataforma Java compatible con el JDK 1.1 y, probablemente, esa hipotética implementación (9) Kaffe. http://www.kaffe.org. todavía requiriese la corrección de abundantes (10) Certificación de Kaffe + Classpath. bugs para pasar los test de compatibilidad. En http://developer.classpath.org/support. cualquier caso, esto será algo que nunca (11) Roxo. https://roxo.dev.java.net. sabremos, ya que sólo pueden certificarse implementaciones con licencia libre de aquellas (12) IKVM. http://www.ikvm.net. versiones de J2SE que se encuentren bajo la (13) JNode. http://www.jnode.org.