Download Implementación de la GNU

IMPLMENTACIONES LIBRES DE J2SE: ESTADO ACTUAL
A. Otero1, A. Sánchez-Mariscal2
1
Departamento 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
diferentes proyectos libres que permiten ejecutar
aplicaciones Java sin depender de software
propietario. Sólo se han tenido en cuenta los
proyectos que en la actualidad muestran una
actividad alta y han obtenido logros considerables,
tomando como baremo de dichos logros las
aplicaciones Java que han sido capaces de compilar
y/o ejecutar.
El trabajo pretende servir de apoyo y guía a
aquellas organizaciones o individuos interesados en
encontrar soluciones que permitan ejecutar en un
entorno completamente libre aplicaciones escritas
en lenguaje Java.
Introducción
Individuos, pequeños grupos de usuarios de
Linux, universidades, empresas e incluso
instituciones gubernamentales han acudido en
alguna ocasión a javaHispano para consultar si
"¿Java es libre?". Irónicamente, a ninguno de
ellos le interesaba la respuesta a esa pregunta, a
la cual se ha tratado de responder en (1). La
pregunta que pretendían formular es "¿Existe
alguna implementación libre del entorno base de
la plataforma Java?". Para entender la diferencia
entre ambas preguntas es necesario conocer qué
es la plataforma Java. Ésta está formada por un
conjunto de especificaciones que definen todas
y cada una de sus partes, y una serie de
implementaciones de estas especificaciones.
El JCP, Java Community Process, es el
organismo que dirige, mediante la creación de
nuevas especificaciones y el mantenimiento de
las ya existentes, la evolución de la plataforma.
Este
organismo
define
su
propio
funcionamiento y las normas por las que se rige;
las vigentes actualmente se recogen en (2).
El JCP consta de dos Comités Ejecutivos (CE),
cada uno de ellos compuesto por 16 miembros,
que se encargan de aprobar las modificaciones y
extensiones de la plataforma; uno se encarga de
las especificaciones relacionadas con J2EE y
J2SE (ediciones empresarial y estándar,
respectivamente, de la plataforma), y el otro de
las relacionadas con J2ME (edición para
pequeños dispositivos). Convertirse en miembro
del JCP es gratis para empresas licenciatarias de
Sun
(empresas
que
implementan
especificaciones de la plataforma con ánimo de
lucro y pagan por ello a Sun), y para personas
que a título individual deseen formar parte del
JCP. Las empresas no licenciatarias han de
pagar 5000 $ por año. En el caso de
organizaciones sin ánimo de lucro e
instituciones académicas, un comité decide si
pueden formar parte del JCP gratis, o han de
pagar 2000 $. Cualquier miembro del JCP
(incluso los individuos) es elegible para los CE.
Las incorporaciones de nuevas tecnologías a la
plataforma Java se realizan a través del JCP,
mediante un JSR, Java Specification Request
(3), un documento que explica la necesidad de
esa nueva tecnología, o de modificación de una
tecnología ya existente, y cómo afectará este
cambio al resto de la plataforma. Cualquiera,
sea o no miembro del JCP, puede proponer
nuevos JSR. Uno de los dos CE del JCP, según
el nuevo JSR afecte a J2ME, o a J2SE/J2EE,
analiza la propuesta y decide si acepta o no la
creación del JSR y, posteriormente, si se
aprueba o no. Estas decisiones se realizan
mediante una votación pública. Para completar
un JSR también se debe desarrollar una
implementación
de
referencia
de
la
especificación y una batería de pruebas que
permitan verificar si una implementación de un
tercero sigue o no la especificación. No hay
impedimentos para que terceras partes creen
otras implementaciones bajo cualquier licencia
y sin pagar royalties.
Por tanto, Java más que un software es un
estándar (especificación), y preguntarse si Java
es libre equivale a preguntarse si Java puede
considerarse un estándar libre. Según los
propios criterios del mundo del software libre,
la respuesta a esta pregunta es afirmativa (1).
En ese trabajo se trata de dar respuesta a la
pregunta ¿Existe alguna implementación libre
del entorno base de la plataforma?. Para ello se
analiza de modo breve, pero exhaustivo dentro
de las posibilidades de los autores, las
implementaciones libres del entorno base de la
plataforma Java (J2SE) o de alguna de sus
partes principales (compilador, máquina virtual
o librerías estándar). Sólo se han estudiado
aquellas implementaciones que permiten
ejecutar
aplicaciones
Java
de
cierta
envergadura, por considerar que son las más
maduras y útiles. El realizar un estudio que
abarque todas las implementaciones existentes
desborda los límites de espacio de este trabajo:
existen, al menos, unas dos docenas.
A continuación se presenta, por este orden, el
estado actual de GCJ, Kaffe, IKVM y JNode.
Junto con GCJ también se analizará el estado de
Classpath, una implementación de las librerías
Java que comparten los cuatro proyectos.
Finalmente, se discute hasta qué punto es viable
ejecutar aplicaciones Java en un entorno
completamente libre y se presentan las
conclusiones extraídas de este trabajo.
GCJ + Classpath
La FSF comenzó su
implementación
del
entorno base de la
plataforma Java en la
segunda mitad de 1998.
Esta
implementación,
con nombre GCJ (4), se integra dentro GCC y
su objetivo es proporcionar soporte para Java
dentro de la colección de compiladores.
GCJ permite compilar código Java a código
máquina, bytecode a código máquina y código
Java a bytecode. Las aplicaciones compiladas
son enlazadas con el entorno de ejecución de
GCJ, libgcj (4), que proporciona las librerías
estándar Java, un colector de basura y un
intérprete de bytecode. libgcj da soporte a una
gran parte de las librerías estándar de Java, entre
ellas el framework de colecciones, java.net,
java.io, java.lang, reflexión, y serialización. En
las versiones 3.X existía una gran cantidad de
código AWT, sin embargo no era suficiente
para aplicaciones reales. En las versiones más
recientes, 4.X, el soporte para AWT está
prácticamente completo y el soporte para Swing
(objetivo del proyecto Free Swing) está muy
avanzado, pero aún no es suficiente para
aplicaciones reales.
Uno de los motivos del éxito de Java son sus
extensas y completas librerías; un compilador o
un intérprete Java sin una implementación de
las librerías base sólo permitirá trabajar con
pequeños programas juguete sin ningún interés
práctico. Las librerías que incorpora libgcj en la
actualidad son una adaptación de GNU
Classpath (5). Este proyecto inicialmente fue
diseñado para trabajar con la máquina virtual
Japhar, una de las primeras máquinas virtuales
libres que se desarrollaron que en la actualidad
está completamente abandonada y cuyo soporte
para Java se encuentra muy desfasado.
Classpath constituye el pilar central de cualquier
implementación funcional actual del JDK, ya
que todas se basan en él. También suele ser el
factor limitante en lo relativo a compatibilidad
con la especificación de una determinada
alternativa. Además de las soluciones que se
recogen en este documento, estas librerías son o
han sido empleadas por JAmiga, Jaos, JamVM,
JC, Jikes, Júpiter, Kissme, SableVM, CACAO y
ORP, entre otras.
Classpath puede considerarse 100% compatible
con las librerías de los JDKs 1.0 y 1.1, versiones
que actualmente son demasiado antiguas para
resultar de interés en desarrollos reales. El
soporte de Swing puede considerarse la única
falla en la compatibilidad respecto a los JDKs
1.2 y 1.3, versiones que, aunque un poco
desfasadas, sí se emplean todavía en entornos de
producción. La compatibilidad con el JDK 1.4,
sin considerar Swing, no es completa aunque
está bastante cercana. A principios de enero del
2006 la rama de Classpath que incluye soporte
para tipos genéricos (la más completa) carecía
de 2 paquetes, 54 clases, 85 métodos y 11
constructores de las librerías estándar del JDK
1.4; y contenía 5 clases, 2 campos y 1
constructor implementados de modo incorrecto
(6). La compatibilidad con el JDK 1.5, a nivel
de librerías, deja bastante que desear: faltan 22
paquetes, 118 clases, 15 interfaces, 8
enumeraciones, 57 campos, 396 métodos y 66
constructores; y 13 clases, 4 campos, 4 métodos
y 3 constructores están implementados de modo
incorrecto (6).
Estos datos fueron obtenidos mediante las
herramientas japitools, Java API compatibility
testing tools (6). japitools consta de dos
herramientas
que
permiten
testar
la
compatibilidad de las librerías Java contra la
implementación de Sun, así como la
compatibilidad hacia atrás entre dos versiones
cualesquiera de las librerías. Las herramientas
son japize y japicompat. Japize es un programa
Java que crea un listado a partir de una API Java
en un formato no legible por un ser humano.
Japicompat toma como entrada dos de estos
listados y compara su compatibilidad binaria
según lo definido en la especificación del
lenguaje Java (7). japitools no está preparada
para tener en cuenta aspectos del API que usen
las nuevas características de Java 1.5, por lo que
realiza la comparación basándose en la
semántica de los binarios de Java 1.4. Ambas
herramientas se ejecutan diariamente contra el
CVS de Classpath.
Hasta hace un par de años libgcj proporcionaba
informes de su compatibilidad a nivel de
librerías con los JDKs de Sun empleando
japitools. En la actualidad han cesado de
proporcionarlos, pero esta debe ser muy similar
a la de Classpath. Sí existe información acerca
de la compatibilidad entre libgcj y Classpath,
pero el último informe data de diciembre de
2004 y es de esperar que en la actualidad estén
mucho más próximos.
Respecto al soporte del lenguaje, GCJ no
soporta las nuevas características de Java 1.5.
Éstas se están desarrollando en GCJX, que se
convertirá en el nuevo compilador Java de
GCC. Actualmente GCJX es capaz de parsear y
analizar código Java 1.4 correctamente, y posee
un soporte bastante amplio de las nuevas
características de Java 1.5, si bien en este último
caso todavía tiene bastantes bugs y el soporte
para tipos genéricos no está terminado.
Actualmente GCJX es capaz de compilar la
versión de Classpath que incluye tipos genéricos
con un poco de trabajo manual.
GCJ carece de herramientas para la gestión de
certificados (keytool), para firmar archivos jar
(jarsigner), herramientas de apoyo al desarrollo
de aplicaciones RMI (rmic y rmiregistry) y
corba, así como herramientas similares a javap,
javah, serialver, native2ascii... Algunas de estas
herramientas se están desarrollando actualmente
bajo el proyecto GNU Classpath::Tools (8), si
bien la única de la cual existen archivos
liberados es gjdoc, equivalente a la herramienta
javadoc del JDK de Sun.
GCJ soporta applets mediante un proyecto
externo, gcjwebplugin, del cual aún no existe
ninguna versión estable. Sin embargo, este
proyecto no tiene implementado ningún gestor
de seguridad, por lo que los applets y
aplicaciones JNLP tienen acceso ilimitado a los
recursos de la máquina, y no soporta todos los
navegadores web.
GCJ da soporte a la depuración de aplicaciones
mediante la herramienta gdb, pero no
implementa el protocolo JDWP (Java Debug
Wire Protocol). El soporte de este protocolo es
opcional: una implementación puede ser Java
compatible sin soportarlo. Sin embargo, es
empleado por la mayor parte de los IDEs y el no
implementarlo impide la integración de GCJ
con ellos. En el futuro, se pretende añadir
soporte para JDWP en Classpath.
Respecto a la licencia bajo la cual se distribuye
GCJ, como es de esperar, es GPL 2.0, a
excepción de libgcj (y Classpath) que se
distribuyen bajo la licencia GPL 2.0 con la
"excepción libgcc". Esta excepción permite
enlazar código con la librería sin que éste quede
bajo el efecto de la licencia GPL.
Kaffe
Kaffe (9)
fue uno de
los
primeros
intentos para conseguir un JDK libre. Su
desarrollo comenzó en 1996 y fue respaldado
por la desaparecida compañía Transvirtual
Technologies. El principal producto de esta
compañía, donante de una considerable cantidad
de código y tiempo de sus desarrolladores para
el proyecto, era una máquina virtual comercial
propietaria, KaffePro, que compartía código con
la libre. En 1998 Kaffe llegó a ganar el premio
de JavaWorld a la mejor máquina virtual.
Este proyecto sufrió dos golpes bastante duros.
Primero su fundador, Tim Wilkinson, dejó de
trabajar para Transvirtual y de tener tiempo para
Kaffe. El proyecto estuvo casi parado durante
un período de dos años comprendido entre 2000
y 2002 en el que no se liberó ningún archivo. En
2002 Jim Pick tomó el relevo a Tim tanto al
frente de Kaffe como de KaffePro, siendo el
líder actual del proyecto. Ese mismo año quebró
Transvirtual Technologies y, por tanto, cesaron
las contribuciones de código y desarrolladores a
Kaffe.
A pesar de estas desventuras y de haber pasado
por un tiempo de baja actividad, el proyecto ha
logrado remontar vuelo. Actualmente libera
revisiones con más frecuencia que GCJ y
SouJava cree que Kaffe junto con Classpath
constituirán la primera implementación libre del
entorno base de la plataforma Java (10); para
trabajar en la línea de la obtención de la
certificación de esta implementación han creado
el proyecto roxo (11).
Kaffe es una máquina virtual tradicional basada
en intérprete y compilador JIT (Just In Time).
Aunque inicialmente contaba con su propia
implementación de las librerías estándar, ésta se
quedó desfasada y se ha ido fusionando poco a
poco con Classpath; en la actualidad el soporte
de Kaffe a nivel de librerías puede considerarse
idéntico al del proyecto GNU. Existen planes
para que en el futuro la máquina virtual
funcione directamente sobre Classpath sin
necesidad de realizar ninguna adaptación.
La principal carencia de este proyecto es la casi
total ausencia de documentación. El equipo de
desarrolladores parece haberse olvidado
completamente de este tema: en su portal ni
siquiera proporcionan información sobre qué
características del lenguaje soporta y cuál es el
estado de desarrollo de las no soportadas. Los
comentarios que acompañan a cada nueva
versión son breves y parcos en detalles. Las
listas de correo públicas y un FAQ bastante
desfasado son la única documentación existente.
Desgraciadamente, Kaffe constituye un
excelente "caso de uso" para una de las críticas
más comunes a los proyectos libres: la falta de
documentación.
Kaffe ha permitido ejecutar Eclipse 3.1 y 3.0,
Tomcat 3.X, 4.X y 5.X, JBoss 3.2, Resin,
HSQLDB, Berkeley DB, Prevayler, SwingWT,
Ant, Rhino, múltiple drivers JDBC y varios de
los proyectos de Apache Jakarta. El proyecto
también tiene un conjunto de herramientas de
apoyo al desarrollo similares a javap, serialver,
rmic, rmiregistry, javadoc... aunque, al igual
que el resto del proyecto, sin documentar. No
soporta JDWP, por lo que no puede ser
integrado con IDEs. Su licencia es GPL.
IKVM
IKVM
(12) es
una
implementación de Java para Microsoft .NET y
Mono, implementación libre de la plataforma
.NET desarrollada por Miguel de Icaza y
apoyada por Novell. Obviamente, para los
objetivos de este artículo, nuestro interés se
centra en la segunda plataforma. IKVM consta
de una máquina virtual Java implementada en
.NET, de una implementación de las librerías
estándar de Java en .NET y de un conjunto de
herramientas para permitir la interoperabilidad
entre java y .NET.
IKVM permite ejecutar aplicaciones Java de dos
modos diferentes. El primero emplea una
máquina virtual que interpreta el bytecode y lo
transforma a IL (Intermediate Language) de
.NET, el cual es a su vez interpretado por el
entorno de ejecución de la segunda plataforma.
El segundo traduce de modo "estático" el
bytecode a IL de .NET, el cual es interpretado
directamente por el entorno de ejecución.
En ambos casos IKVM parte de bytecode Java,
no disponiendo de herramientas que permitan
compilar el código fuente. Por tanto, con vistas
a conseguir un entorno base completo libre de la
plataforma Java, IKVM necesita de un
compilador libre. También deja abierto el
problema de la depuración del código fuente
Java, así como las herramientas de apoyo al
desarrollo (javadoc, jarsigner, javap...).
Al igual que Kaffe y GCJ, IKVM se basa en
Classpath para obtener las librerías estándar,
aunque debe añadir a éstas cierto código
específico. Parte de este código son los peers de
AWT para .NET, desarrollo que actualmente no
constituye una prioridad para el proyecto. Por
tanto, en lo relativo a soporte de librerías IKVM
se encuentra por debajo de los anteriores. En lo
referente al lenguaje, IKVM soporta
completamente Java 1.4, aunque no 1.5.
Este proyecto podría permitir escribir
programas con sintaxis Java empleando las
librerías de Mono, supliendo así las deficiencias
de Classpath. De este modo se podrían construir
programas que se ejecutasen en un entorno
completamente libre, aunque quedaría por
resolver la parte de compilación.
Algunas aplicaciones que han sido ejecutadas
con éxito con IKVM son Eclipse, Jython y
JBoss. La licencia de IKVM es tipo Apache,
aunque para funcionar necesita de Classpath,
con el que se puede enlazar debido la excepción
libgc.
JNode
JNode,
Java
New Operating
System Design
Effort (13), es un
proyecto
con
licencia LGPL cuyo objetivo es construir un
sistema operativo fácil de instalar y usar que
permita ejecutar de modo seguro cualquier
aplicación Java. Los orígenes del proyecto se
remontan a 1996. Por aquel entonces Ewout
Prangsma, fundador del proyecto, se planteó el
reto de construir no sólo una máquina virtual
Java, sino un sistema operativo completo. Tras
dos intentos fallidos en los que se empleó C y
ensamblador nació JNode, programado en Java
y con una cantidad mínima de ensamblador. En
la actualidad JNode es funcional y soporta una
gran parte del hardware más común para PCs.
JNode depende de Classpath para obtener las
librerías estándar de Java. En lo que destaca el
proyecto es en el soporte del lenguaje: en la
actualidad
soporta
todas
las
nuevas
características de Java 1.5. No obstante, debe
resaltarse que el objetivo de JNode es sólo
proporcionar un entorno de ejecución para
aplicaciones Java, por lo que no han tenido que
desarrollar un compilador para Java 1.5, sino
solamente un intérprete tipo JIT.
De modo similar a IKVM, JNode resuelve el
problema de ejecutar aplicaciones Java
empleando sólo software libre, aunque con un
mayor soporte para el lenguaje (soporte que
puede considerarse completo) y mejor soporte
para las librerías, ya que se encuentra al mismo
nivel que Classpath y no por debajo de éste.
Nuevamente, queda por resolver la compilación
y el proporcionar herramientas de apoyo al
desarrollo.
Discusión
El principal factor limitante en la
compatibilidad de todas las implementaciones
son las librerías, en especial el soporte de
Swing, imprescindible para obtener un JDK 1.2
compatible o superior. En este sentido, cabe
destacar el espíritu de cooperación de la
comunidad del software libre que, viendo lo
ardua que era la tarea, abandonó las múltiples
implementaciones paralelas para cerrar filas
entorno a Classpath.
Quizás alguien podría pensar que, como
solución transitoria, podría emplearse un
compilador y una máquina virtual libres contra
las librerías de Sun. Esto no es posible ni
técnica ni legalmente. La imposibilidad legal
surge de la licencia bajo la cual se distribuyen
dichas librerías. La técnica, es que estas
librerías realizan múltiples llamadas a métodos
nativos no documentados que implementa la
máquina virtual de Sun. Intentar emplear las
librerías con otra máquina virtual supondría
implementar en ella esos métodos no
documentados cuya funcionalidad se conoce.
Aunque se han obtenido importantes logros
ejecutando aplicaciones de envergadura, sobre
todo con Kaffe y GCJ, también hay que
reconocer que el ejecutar estas aplicaciones
requiere, habitualmente, de bastante trabajo
manual y artimañas que se escapan a las
capacidades de un usuario medio. Uno de los
ejemplos más conocidos es el trabajo realizado
por Debian y otras distribuciones para conseguir
que funcionase OpenOffice.org 2.0.
Hay dos impedimentos principales a la hora de
ejecutar un código fuente Java con software
libre. El primero, el soporte de Swing. La
solución pasa por emplear otras alternativas
como AWT o SWT; de todos modos, ha habido
ciertos casos de éxito en la compilación de
aplicaciones que usan Swing. El segundo
impedimento son las dependencias del código
fuente con paquetes com.*; estos paquetes
pertenecen al JDK de Sun pero no forman parte
de las librerías estándar. Es curioso que esta sea
una de las causas de los fracasos a la hora de
llevar aplicaciones Java a una plataforma libre,
sobre todo cuando el propio Sun recomienda no
emplear dichos paquetes ya que pueden cambiar
en el futuro y emplearlos rompe la portabilidad
entre distintas implementaciones del entorno
base. Sin embargo, esta es la causa de muchos
fracasos de GCJ y Kaffe.
versión 2.6 del JCP; esto es, sólo podría
certificarse un JDK compatible con Java 1.5.
En la actualidad, tanto la implementación de
Kaffe como la de GCJ dedican la mayor parte
de esfuerzos a desarrollar un entorno de
ejecución, que no un JDK completo. Esto viene
motivado por conseguir entornos de ejecución
completamente libres para poder ejecutar
software libre escrito en Java en las
distribuciones de Linux. Si bien el fin es loable,
no lo es tanto una de sus consecuencias: la falta
casi total de herramientas libres para el
desarrollo de aplicaciones Java. Si ejecutar
aplicaciones Java en un entorno completamente
libre es complicado, el desarrollarlas es
imposible o extremadamente complejo.
El soporte para Java 1.4, excluyendo Swing, es
relativamente alto. En el caso de Java 1.5,
última versión de la plataforma que ha
introducido un número considerable de
cambios, deja bastante que desear.
En el estudio no se ha incluido Harmony, una
implementación desarrollada por Apache
Software Foundation, por no disponer en la
actualidad de ninguna solución funcional. No
obstante, es un proyecto con grandes
posibilidades de éxito que no se debe perder de
vista. Aunque no podrá reutilizar ningún trabajo
de los anteriores, ya que se distribuyen bajo
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
proyecto cuenta con el apoyo de una comunidad
tan activa y numerosa como la de Apache. Por
otro, la excelente relación que la fundación
mantiene con múltiples empresas y el hecho de
que el código fuente del proyecto podría
utilizarse en productos comerciales augura un
notable apoyo empresarial. Hasta la fecha, Intel
ya ha contribuido con código para temas
relacionados con criptografía y seguridad, e
IBM ha donado los paquetes java.lang, java.util,
java.io y java.net, así como una interfaz que
permitirá emplear las librerías de Harmony con
cualquier máquina virtual.
Conclusiones
Actualmente sólo se podría conseguir una
implementación completa del entorno base de la
plataforma Java compatible con el JDK 1.1 y,
probablemente, esa hipotética implementación
todavía requiriese la corrección de abundantes
bugs para pasar los test de compatibilidad. En
cualquier caso, esto será algo que nunca
sabremos, ya que sólo pueden certificarse
implementaciones con licencia libre de aquellas
versiones de J2SE que se encuentren bajo la
No obstante, se ha demostrado que es posible
compilar aplicaciones a código nativo (GCJ) y
ejecutarlas en una máquina virtual tradicional
(Kaffe) empleando única y exclusivamente
software libre: Eclipse, OpenOffice.org, JOnAS,
JBoss, Tomcat, Resin y Ant han sido los
principales logros hasta la fecha.
Aun a riesgo de ser tachados de optimistas,
creemos que estamos a no mucho más de un par
de años de tener una implementación completa
funcional de Java 1.5, que podría ser Kaffe +
Classpath, GCJ + Classpath o Harmony.
Palabras clave: Java, GCJ + Classpath, Kaffe,
IKVM.
Bibliografía:
(1) A Otero, "Estándares libres y Java: ¿Es el
JPC un organismo que crea estándares libres?. II
Congreso javaHispano, páginas 87-98. Madrid,
2004.
(2) JCP v. 2.6. http://jcp.org/aboutJava
/communityprocess/first/jsr215/JCP2_6.pdf.
(3) Java Specification Request.
http://www.jcp.org/ en/jsr/overview.
(4) GCJ. Http://gcc.gnu.org/java.
(5) Classpath. http://www.classpath.org.
(6) Japitools. http://www.kaffe.org/~stuart/japi.
(7) J. Gosling, B. Joy, G. Steele, G. Bracha. The
Java Language Specification. Addison Wesley,
2003.
(8)Classpath::Tools.
http://www.gnu.org/software/classpath/cp-tools.
(9) Kaffe. http://www.kaffe.org.
(10) Certificación de Kaffe + Classpath.
http://developer.classpath.org/support.
(11) Roxo. https://roxo.dev.java.net.
(12) IKVM. http://www.ikvm.net.
(13) JNode. http://www.jnode.org.