GCJ CrossCompiling

[nocturne]

Moinsen,

kann mir jemand sagen mit welchem Befehl ich eine SWT Applikation in eine .exe Applikation kompiliere?

 

[Wildcard]

gar nicht?

 

[tuxedo]

Die Antwort passt schon allein von der Formulierung her nicht zur Frage ;-)

@nocturne:

Wirf doch mal google an. Habe irgendwo mal HowTos gesehen wie man Eclipse mit GCJ in ne EXE compiliert. Vielleicht kannst du dir da was abgucken.

 

[Wildcard]

*nachles*
Huch, wann haben die denn das eingebaut?
*sehr skeptisch sein* ???:L

 

[tuxedo]

*verwirrt bin*

Dass GCJ aus Java -> (begrenzt) nativen Maschinen-Code machen kann weißt du aber?

 

[Wildcard]

Ja, allerdings auch nur sehr begrenzt für AWT und nicht wirklich für Swing.
Das SWT jetzt funktionieren soll war mir neu.
Aber andererseits... wer braucht's? :wink:

 

[tuxedo]

Aber andererseits... wer braucht's? :wink:

Zumindest mal die, die GCJ erfunden/entwicklet haben... Denn sonst gäb's das ja nicht.. Was sie aber dazu veranlasst hat und ob's Sinn macht sei mal dahingestellt.

 

[robertpic71]

Ich hab das mal vor ca. einem Jahr gestestet und als "unbrauchbar" eingestuft, aber hier meine Erfahrungen:

1. Es gibt das Eclipse Plugin GCJ-Builder, siehe http://gcjbuilder.sourceforge.net/. Der sollte das für dich erledigen - hat er bei mir aber nicht. Aber er hat alles zumindest soweit vorbereitet, dass ich nur den letzten Schritt per Commandline ausführen musste.

2. Damit das (Compilieren) unter Windows funktioniert, brauchst du Cygwin. Danach brauchst du nur noch eine DLL-Datei + das Exefile.

2b.) Alternativ soll da auch was mit MiniGW funktionieren. Die MiniGW-Lösung sollte keine DLL-Datei benötigten - wobei man für SWT sowie extra DLL's braucht.

Bis zum Testen mit SWT bin ich gar nicht gekommen. Ich bin über eine eine einfache Konsolenapplikaton gar nicht herausgekommen. Das Problem sind die verwendeten Libs.

Auch die verwendete Jardateien sollten mitkompiliert - und nur die wenigsten haben sich compilieren lassen. GCJ kann schon Probleme beim Compilieren von Sourcecode machen, erst recht beim Compilieren von Bytecode.

Es gibt auch die Möglichkeit die Jar-Dateien nicht zu kompilieren. Dann wird der Bytecode zur Laufzeit interpretiert. Das habe ich mir aber erst gar nicht angefangen...

Eine VM gibt es auch beim GCJ-Compilat. Deshalb hat ein HelloWorld auch 8MB.

Noch eine Beispiel von GCJ:

Die Datenbank H2 wurde mit gcj gewandelt:
- die Windowsversion wurde mangels Stabiltät wieder zurückgezogen
- die Linuxversion läuft, aber langsamer als mit der die der JVM

Es gibt auch einen kommerziellen Nativecompiler, aber die Resonanz im Internet haben mir auch nicht viel mehr Hoffnung gemacht...

/Robert

 

[Linuxhippy]

Eine VM gibt es auch beim GCJ-Compilat. Deshalb hat ein HelloWorld auch 8MB.

Stimmt nicht - GCJ erzeugt Maschinencode, daher gibts auch keine "virtuelle Maschine".

Mfg Clemens

 

[robertpic71]

Eine VM gibt es auch beim GCJ-Compilat. Deshalb hat ein HelloWorld auch 8MB.

Stimmt nicht - GCJ erzeugt Maschinencode, daher gibts auch keine "virtuelle Maschine".

Mfg Clemens

Dann lies nochmal meinen Beitrag genau - oder die Doku...


Wie ich schon oben geschrieben habe: Ist es auch möglich compilierte Programme mit Java Bytedateien (z.B. Jararchiven ) zu mixen. Dafür braucht er dann die VM.

Hier ein Ausschnitt aus der FAQ:

1.7 Can I interface byte-compiled and native java code

libgcj has a bytecode interpreter that allows you to mix .class files with compiled code. It works pretty transparently: if a compiled version of a class is not found in the application binary or linked shared libraries, the class loader will search for a bytecode version in your classpath, much like a VM would. Be sure to build libgcj with the --enable-interpreter option to enable this functionality.
...

/Robert

 

[nocturne_]

http://www.webmasterwork.com/page/43997-jni-alles-klappt-bis-zur-bindung.html

 

[FArt]

Die VM hat mehrere Aufgaben, nicht nur den Bytecode zu compilieren, deswegen braucht man etwas adäquates auch in der nativen Variante.

Was in so einer VM steckt kann man z.B. bei SUN nachlesen.

Nachdem hier statischer Maschinencode produziert wird, ist der natürlich langsamer als Javacode. Mittlerweile leistet die Optimierung (JIT und Hotspot, Inlining, Early Writes ,...) bessere Arbeit als oft nativer Code (nicht generell, abhängig vom Anwendungsfall).

Wann macht der Krempel also Sinn: in meinen Augen nie.. ich finde eine funktionierende Java VM gehört zu einer BS Installation.