Compilador GNU para Java

El compilador GNU para Java ( GCJ ) es un compilador gratuito descontinuado para el lenguaje de programación Java . Formaba parte de la Colección de Compiladores GNU . ^{[ 2 ] [ 3 ]}

GCJ compila el código fuente de Java a bytecode de la máquina virtual de Java (JVM) o a código máquina para diversas arquitecturas de CPU . También puede compilar archivos de clase y JAR completos que contienen bytecode a código máquina. ^{[ 4 ] [ 5 ]}

El código 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 bibliotecas libgcj . GCJ 4.3 utiliza el compilador Eclipse para Java como interfaz. ^{[ 6 ]}

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 era incompleto. "Una vez que el soporte para AWT funcione, se podrá considerar el soporte para Swing. Hay al menos una implementación parcial de software libre de Swing que podría ser utilizable." ^{[ 7 ]} Para cuando se eliminó, GCC tenía soporte para hasta la versión 1.4 de Java (y por lo tanto carecía de soporte para la mayoría de las características posteriores, como genéricos , anotaciones o módulos JPMS ; a pesar de esto, se implementaron partes de la biblioteca java.nio ). ^{[ 8 ]} GNU Classpath nunca se completó ni siquiera al estado de Java 1.2 y ahora parece haber sido abandonado por completo.

Hasta 2015, no se anunciaron nuevos desarrollos de GCJ y el producto estaba en modo de mantenimiento , mientras que el desarrollo de la cadena de herramientas Java de código abierto se realizaba 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 de GCC 6.

La función de compilación en GCJ debería tener un tiempo de inicio más rápido que el bytecode equivalente lanzado en una JVM al compilar código Java a código máquina. ^{[ 13 ]}

La Interfaz Nativa Compilada ( CNI ), anteriormente llamada "Interfaz Nativa de 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++ . ^{[ 14 ]} Podía funcionar con C++ hasta C++17 (la última versión de C++ compatible con GCC 6.5, la versión final de GCJ).

CNI se asemeja mucho al marco de trabajo de la Interfaz Nativa de Java (JNI), que viene de serie con varias máquinas virtuales de Java .

GCJ admite además un " enlace Java " con , que se utiliza al hacer referencia a código Java compilado por GCJ y utilizado en código C++ para indicar que un símbolo que se consume proviene de Java. ^{[ 15 ]}extern"Java"

Por ejemplo, considere el siguiente código Java:

paquete org.wikipedia.examples ;clase pública Foo { int público agregar ( int a , int b ) { return a + b ; } }

Luego, desde C++ se puede consumir de la siguiente manera:

#include <gcj/cni.h> #include <java/lang/Object.h>// Encabezado generado automáticamente #include <org/wikipedia/examples/Foo.h>using namespace java :: lang ;usando org :: wikipedia :: ejemplos :: Foo ;extern "Java" {int addThroughJava ( int a , int b ) { Foo * foo = new Foo (); return foo -> add ( a , b ); // Nota: foo no debe eliminarse, ya que es recolectado por el recolector de basura }namespace org :: wikipedia :: examples { // Herencia de un objeto Java // Solo se admite la herencia simple class Bar : public Object { // ... }; }}

Una implementación de libjava (que contiene los encabezados de C++ para la biblioteca de clases de Java ) se puede encontrar aquí (en una versión de GCC 6). Las clases de Java se exponen a C++ como archivos de encabezado (autogenerados) por una clase por encabezado ^{[ 16 ]} , preservando la estructura de espacios de nombres por paquete de Java . ^{[ 17 ]}

Todos los tipos de referencia de Java Xse traducen a un puntero X*en C++. Por ejemplo, java.lang.Stringse convierte en java::lang::String*. ^{[ 18 ]} Debido a que las clases de Java son administradas por el recolector de basura de Java , no deben eliminarse usando el deleteoperador de C++, aunque ambas se instancian usando new^{[ 19 ]} ; los objetos de Java son eliminados automáticamente por el recolector de basura. ^{[ 20 ]} Las clases de Java, cuando se usan en C++, mantienen el mismo orden y alineación de campos, y no ampliarán los tipos nativos de 8 bits y 16 bits a 32 bits. ^{[ 21 ]}

La reflexión de Java sobre objetos Java en C++ es posible usando CNI, que incluye jfieldIDy jmethodID(como se ve en JNI). ^{[ 22 ]} (Java ya ofrece java.lang.reflect.Field/ java.lang.reflect.Method, pero estos no son utilizados por GCJ). Si bien los genéricos de Java nunca se implementaron para cuando se eliminó GCJ, se habían llevado a cabo algunas discusiones sobre cómo operarían con C++ (por ejemplo, traduciendo directamente los genéricos a plantillas u omitiéndolos por completo, lo que hace la JVM en tiempo de ejecución).

Los tipos primitivos de Java pueden mapearse exactamente a los tipos primitivos correspondientes de C/C++. Sin embargo, en el caso de que no lo hagan (ya que C/C++ no especifica el ancho exacto de los tipos enteros), se proporcionan definiciones de tipo como sigue: ^{[ 23 ]}

voidSe corresponden exactamente igual entre lenguajes, ya que no hacen referencia a ningún valor. Se recomendó usar estos typedefs de Java en lugar de los tipos nativos de C++ para evitar posibles errores. ^{[ 23 ]}

Los arrays de Java se implementan con la plantilla de clase JArray<T>y heredan java::lang::Object(e implementan ). Se proporcionan definiciones de tipo adicionales para cada puntero a array de tipos primitivos de Java. ^{[ 24 ]}operator[]

Las funciones variádicas en Java se representan internamente como matrices; por lo tanto, en GCJ una firma con un parámetro variádico como se genera como .voidf(T...args);voidf(JArray<T>args);

Además, las clases comunes reciben los siguientes typedefs: ^{[ 18 ]}

Tenga en cuenta que en JNI, jobjecty jstringeran jclassmanejadores opacos sin ningún dato ^{[ 25 ] [ 26 ]} ; en CNI, las clases Java a las que apuntan tienen datos.

Además, todas las clases de Java Xexponen un campo estático en C++, que se comporta de forma equivalente a en Java. Sin embargo, el campo es de tipo (no ). Java se tradujo originalmente al C++ más antiguo (sin embargo, la constante de puntero nulo puede sustituirse debido a conversiones implícitas). ^{[ 27 ]} Las clases adicionales, y denotan respectivamente tipos de referencia no escaneados (que no serán comprobados por el compilador y pueden almacenar cualquier estructura de datos de C/C++), y datos que pueden ser marcados por el administrador de memoria y ser recolectados por el recolector de basura. ^{[ 28 ]}X::class$X.classclass$java::lang::Classjava::lang::Class*nullNULLnullptrgnu::gcj::RawDatagnu::gcj::RawDataManaged

En C++, java::lang::String*(o jstring) deben crearse manualmente utilizando funciones de utilidad CNI (análogas a las de JNI); no pueden convertirse implícitamente desde o C++ . ^{[ 29 ]}constchar*std::string

Los bloques Java synchronizedse implementan en C++ utilizando la ::JvSynchronizeclase (que reside en el espacio de nombres global). ^{[ 30 ]} Por ejemplo, lo siguiente es equivalente a Javasynchronized(obj){/* code... */}

{ JvSynchronize _ ( obj ); // crea un bloqueo ficticio, destruido al finalizar el ámbito // código... }

En C++, cualquier clase que aplique el modelo de herencia de Java debe heredar de la java::lang::Objectclase base y puede heredar como máximo una clase base. Aunque estaba previsto, la compatibilidad con la herencia de interfaces nunca se implementó en GCJ antes de su eliminación. ^{[ 31 ]} A pesar de esto, existía un atributo para marcar una clase como una interfaz de Java, junto con una pragma . ^{[ 15 ]} Sin embargo, se podían implementar métodos de interfaces, pero llamar a un método de una superinterfaz requería convertir la clase de nuevo a la superinterfaz. ^{[ 31 ]} Además, los especificadores de acceso de Java nunca se aplicaron estrictamente en C++; solo los campos y métodos de Java se mapeaban correctamente a en C++, pero todo lo demás se mapeaba a . ^{[ 21 ]}[[gnu::java_interface]]#pragma interfaceprivateprivatepublic

Los métodos se corresponden directamente entre Java y C++ con los mismos nombres y tipos correspondientes, y se conservan los métodos estáticos (que aún se llaman ::para su resolución). La modificación de nombres para los métodos sobrecargados utiliza el mismo esquema de codificación entre Java y C++. Si bien Java no permite que un constructor sea un método nativo en sí mismo, un constructor puede llamar a un método nativo. ^{[ 32 ]}

La asignación fallida de una clase Java generará una excepción java::lang::OutOfMemoryError. ^{[ 33 ]}

libgcj utiliza internamente señales POSIX , y el uso de la misma señal puede interferir con libgcj o incluso provocar su fallo. Por ejemplo,genera una señal,utiliza otra señal, mientras que otras señales (potencialmente dependientes de la plataforma) pueden ser utilizadas por el gestor de memoria o. ^{[ 28 ]}SIGSEGVjava::lang::NullPointerExceptionjava::lang::Runtime::exec()SIGCHLDjava::lang::Thread::interrupt()

paquete org.wikipedia.examples ;clase pública MyInteger { int i privado ;public MyInteger ( int i ) { this . i = i ; }public int obtener () { return i ; }public void set ( int j ) { i = j ; }public static final MyInteger ZERO = new MyInteger ( 0 ); }

#include <gcj/cni.h> #include <org/wikipedia/examples/MyInteger.h>usando org :: wikipedia :: ejemplos :: MyInteger ;MyInteger * mult ( MyInteger & p , jint k ) { if ( k == 0 ) { return MyInteger :: ZERO ; // Acceso a miembro estático. }return new MyInteger ( p.get ( ) * k ) ; }

#pragma GCC java_exceptions#include <gcj/cni.h> #include <java/lang/Integer.h> #include <java/lang/Math.h> #include <java/lang/NumberFormatException.h> #include <java/lang/String.h> #include <java/lang/System.h> #include <java/io/File.h> #include <java/io/IOException.h> #include <java/net/URI.h>using namespace java :: lang ; using java :: io :: File ; using java :: io :: IOException ; using java :: net :: URI ;// Literal auxiliar para crear java::lang::String* String * operator "" _js ( const char * s , [[ maybe_unused ]] size_t len ​​) { return :: JvNewStringLatin1 ( s ); }int main ( int argc , char * argv []) { try { :: JvCreateJavaVM ( nullptr ); :: JvAttachCurrentThread ( nullptr , nullptr ); :: JvInitClass ( & System :: class $ ); :: JvInitClass ( & Math :: class $ ); JArray < String *>* args = :: JvConvertArgv ( argc , argv ); // String[] argsjdouble one = Math :: sin ( Math :: PI / 2 ); URI * location = new URI ( "file:///C:/temp/example.txt" _js ); File * file = new File ( location ); System :: out -> println ( file -> getAbsolutePath ());String * invalid = "no es un número" _js ; jint result = Integer :: parseInt ( invalid ); } catch ( NumberFormatException * e ) { System :: err -> println ( "Error al formatear el número: " _js -> concat ( e -> getMessage ())); e -> printStackTrace (); } catch ( IOException * e ) { System :: err -> println ( "Error en la operación de E/S: " _js -> concat ( e -> getMessage ())); e -> printStackTrace (); } return 0 ; }

• Comparación de Java y C++
• Excelsior JET (compilador de código nativo Java de Excelsior)
• Té helado
• Café
• SableVM
• JamVM
• Armonía Apache
• Jikes
• GraalVM
• máquina virtual Java
• Implementaciones Java gratuitas
• Kotlin/Native , que utiliza LLVM para la compilación AOT.
• C++/CX y C++/CLI , ambos modificados de C++ para interoperar con .NET.

• Sitio web oficial . GCC . GNU. 30 de marzo de 2007. Archivado del original el 9 de mayo de 2007.
• "Manual GCJ" . Archivado del original el 22 de agosto de 2016.
• "Documentación de GCC - 11 Acerca de CNI" . GCC . Proyecto GNU. 26 de octubre de 2018. Archivado del original el 11 de diciembre de 2025.
• Wielaard, Mark (6 de abril de 2005). "GCJ: pasado, presente y futuro" . LWN. Archivado del original el 2 de agosto de 2019.