Kompilator GNU dla Javy — GNU Compiler for Java

Kompilator GNU dla Javy
Gcj2.png
Deweloper(zy) Projekt GNU
Pierwsze wydanie 6 września 1998 ; 23 lata temu ( 1998-09-06 )
Wersja ostateczna
6.5 / 26 października 2018 ; 2 lata temu ( 26.10.2018 )
System operacyjny Uniksopodobny
Rodzaj Kompilator
Licencja GNU GPL
Strona internetowa gcc .gnu .org

GNU Compiler for Java ( GCJ ) jest wolny kompilator dla języka programowania Java . Był częścią GNU Compiler Collection przez ponad dziesięć lat, ale od 2017 roku nie jest już utrzymywany i nie będzie częścią przyszłych wydań.

GCJ kompiluje kod źródłowy Java do kodu bajtowego Java Virtual Machine lub kodu maszynowego dla wielu architektur procesora . Może również kompilować pliki klas i całe JARy, które zawierają kod bajtowy do kodu maszynowego.

Historia

Oryginalne źródło bibliotek uruchomieniowych GCJ pochodzi z projektu GNU Classpath , ale istnieje różnica w kodzie między libgcjbibliotekami. GCJ 4.3 wykorzystuje kompilator Eclipse dla Javy jako front-end.

W 2007 roku wykonano dużo pracy, aby zaimplementować obsługę dwóch graficznych API Javy w GNU Classpath : AWT i Swing . Wsparcie oprogramowania dla AWT jest wciąż w fazie rozwoju. „Gdy obsługa AWT działa, można rozważyć obsługę Swing. Istnieje co najmniej jedna częściowa implementacja Swing w wolnym oprogramowaniu, która może być użyteczna”. GNU CLASSPATH nigdy nie została ukończona nawet do wersji Java 1.2, a teraz wydaje się, że została całkowicie porzucona.

Od 2015 r. GCJ nie ogłaszało żadnych nowych zmian, a produkt był w trybie konserwacji , przy czym rozwój open-source'owego łańcucha narzędzi Java odbywał się głównie w ramach OpenJDK . GCJ został usunięty z bagażnika GCC 30 września 2016 r. Ogłoszenie jego usunięcia zostało ogłoszone wraz z wydaniem GCC 7.1, które go nie zawiera. GCJ pozostaje częścią GCC 6.

Wydajność

Funkcja kompilacji w GCJ powinna mieć szybszy czas uruchamiania niż odpowiednik kodu bajtowego uruchamianego w JVM podczas kompilowania kodu Java do kodu maszynowego.

Skompilowany interfejs natywny (CNI)

Zestawione Native Interface ( CNI ), wcześniej o nazwie „Cygnus Native Interface”, to ramy oprogramowanie dla GCJ który pozwala kodu Java do rozmowy i być nazywany przez, natywnych aplikacji (programy specyficzne dla sprzętu i operacyjnego systemu platformy) i biblioteki napisane w C++ .

CNI bardzo przypomina framework JNI (Java Native Interface), który jest standardem w różnych maszynach wirtualnych Java .

Porównanie użycia języka

Autorzy CNI twierdzą, że mają różne zalety w stosunku do JNI:

Używamy CNI, ponieważ uważamy, że jest to lepsze rozwiązanie, szczególnie w przypadku implementacji Java, która opiera się na założeniu, że Java jest po prostu innym językiem programowania, który można zaimplementować przy użyciu standardowych technik kompilacji. Biorąc to pod uwagę oraz ideę, że języki zaimplementowane przy użyciu Gcc powinny być kompatybilne tam, gdzie ma to sens, wynika z tego, że konwencja wywoływania Java powinna być tak samo jak praktyczna do tej używanej w innych językach, zwłaszcza C++, ponieważ możemy myśleć o Javie jako podzbiór C++. CNI to po prostu zestaw funkcji pomocniczych i konwencji zbudowanych na założeniu, że C++ i Java mają *tę samą* konwencję wywoływania i układ obiektów; są kompatybilne binarnie. (To uproszczenie, ale wystarczająco blisko).

CNI zależy od klas Javy występujących jako klasy C++. Na przykład, biorąc pod uwagę klasę Java, 

public class Int
{
   public int i;
   public Int(int i) { this.i = i; }
   public static Int zero = new Int(0);
}

klasę można wykorzystać w ten sposób: 

#include <gcj/cni.h>
#include <Int>

Int *mult(Int *p, int k)
{
  if (k == 0)
    return Int::zero;  // Static member access.
  return new Int(p->i * k);
}

Zobacz też

Bibliografia

Zewnętrzne linki