El compilador GNU para Java ( GCJ ) es un compilador gratuito descontinuado para el lenguaje de programación Java . Era parte de la Colección de Compiladores GNU . [3] [4]
GCJ compila el código fuente de Java en código de bytes de máquina virtual Java (JVM) o en código de máquina para varias arquitecturas de CPU . También podría compilar archivos de clase y JAR completos que contengan código de bytes en código de máquina. [5] [6]
La fuente original de las bibliotecas de tiempo de ejecución de GCJ proviene del proyecto GNU Classpath , pero existe una diferencia de código entre las libgcjbibliotecas. GCJ 4.3 utiliza el compilador Eclipse para Java como interfaz. [7]
En 2007, se trabajó mucho para implementar soporte para las dos API gráficas de Java en GNU Classpath : AWT y Swing . El soporte de software para AWT aún está en desarrollo. "Una vez que el soporte AWT esté funcionando, se podrá considerar el soporte Swing. Hay al menos una implementación parcial de software libre de Swing que puede ser utilizable". [8] GNU CLASSPATH nunca se completó ni siquiera hasta el estado de Java 1.2 y ahora parece haber sido abandonado por completo.
A partir de 2015, no se anunciaron nuevos desarrollos por parte de GCJ y el producto estaba en modo de mantenimiento , y el desarrollo de la cadena de herramientas Java de código abierto se realiza principalmente dentro de OpenJDK . [9] GCJ fue eliminado del tronco de GCC el 30 de septiembre de 2016. [10] [11] El anuncio de su eliminación se realizó con el lanzamiento de GCC 7.1, que no lo contiene. [12] GCJ sigue siendo parte del GCC 6.
La función de compilación en GCJ debería tener un tiempo de inicio más rápido que el código de bytes equivalente lanzado en una JVM al compilar código Java en código de máquina. [13]
La interfaz nativa compilada ( CNI ), anteriormente denominada "interfaz nativa Cygnus", es un marco de software para GCJ que permite que el código Java llame y sea llamado por aplicaciones nativas (programas específicos de una plataforma de hardware y sistema operativo) y Bibliotecas escritas en C++ .
CNI se parece mucho al marco JNI (Java Native Interface) que viene como estándar con varias máquinas virtuales Java .
Los autores de CNI afirman varias ventajas sobre JNI: [14]
Usamos CNI porque creemos que es una mejor solución, especialmente para una implementación de Java que se basa en la idea de que Java es simplemente otro lenguaje de programación que se puede implementar utilizando técnicas de compilación estándar. Teniendo en cuenta eso, y la idea de que los lenguajes implementados usando Gcc deberían ser compatibles cuando tenga sentido, se deduce que la convención de llamada de Java debería ser lo más similar posible a la utilizada para otros lenguajes, especialmente C++, ya que podemos pensar en Java como un subconjunto de C++. CNI es sólo un conjunto de funciones auxiliares y convenciones basadas en la idea de que C++ y Java tienen la *misma* convención de llamadas y diseño de objetos; son compatibles binariamente. (Esta es una simplificación, pero lo suficientemente cercana).
CNI depende de que las clases de Java aparezcan como clases de C++. Por ejemplo, [15] dada una clase Java,
clase pública Int { pública int i ; público Int ( int i ) { este . yo = yo ; } public static Int cero = nuevo Int ( 0 ); } se puede utilizar la clase así:
#incluye <gcj/cni.h> #incluye <Int> Int * mult ( Int * p , int k ) { si ( k == 0 ) return Int :: cero ; // Acceso a miembros estáticos. devolver nuevo Int ( p -> i * k ); } .svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
