[peschmae]

Das ist ja mittlerweile nicht mehr ne wahnsinnige Neuigkeit - Changelog gibts hier: http://gcc.gnu.org/gcc-4.0/changes.html

Das coolste an der Sache ist (ausser dem erneuten sync mit dem Classpath Projekt was verbesserten Swing und Awt Support (lies es geht langsam ein bisschen) und viele neue Klassen bringt) dass Eclipse mittlerweile ohne Änderungen am Sourcecode einfach so mit GIJ läuft.
Die diversen Archive können auch mit GCJ kompiliert und von GIJ verwendet werden.

Anleitung: http://developer.classpath.org/media...sspathShowcase

MfG Peschmä

P.S. nein ein mit GCJ kompilierstes Eclipse ist *nicht* schneller als Eclipse mit Suns JVM. Aber es läuft - das gefällt mir schon sehr gut.

[peschmae]

Habs gestern bis heute noch mit
-march=pentium3 -O2 -ffast-math -ftree-vectorize -fomit-frame-pointer -shared -findirect-dispatch
kompiliert (man bemerke die hyperneuen endcoolen -ftree-vectorize-Optimierungen, die allerding extrem lang brauchen) - jetzt ists etwas schneller beim starten als Suns Java.

MfG Peschmä

[Sym]

Zitat von peschmae

P.S. nein ein mit GCJ kompilierstes Eclipse ist *nicht* schneller als Eclipse mit Suns JVM. Aber es läuft - das gefällt mir schon sehr gut.

Aber es ist wenigstens nicht langsamer, oder?

edit: wird die JVM beim kompilieren in Maschinencode eigentlich direkt mit hineinkompiliert oder ist diese gar nicht mehr nötig?

Wie sieht das mit dem Decompilieren von solchen Klassen aus?

[peschmae]

Zitat von Sym

Aber es ist wenigstens nicht langsamer, oder?

Naja. Nicht viel. Ein klein bisschen schon beim Starten - wies im Allgemeinen aussieht weiss ich nicht. Eventuell ist der Classloader von GCJ auch einfach langsamer als der von Sun oder so...

edit: wird die JVM beim kompilieren in Maschinencode eigentlich direkt mit hineinkompiliert oder ist diese gar nicht mehr nötig?

Jein. Kommt drauf an. Bei Eclipse nach obiger Anleitung wird immer noch gij verwendet (der Interpreter der zu gcj gehört) - die jars werden dann zu Shared-Bibliotheken kompiliert. Gibts die in der Datenbank werden die geladen, sonst nimmt gij das Zeugs aus den Jars.

Aber wenn du eigene Apps kompilierst ist das dann ein fertiges Programm. Ein *richtiges* Programm. Nix vm. Ausser wenn du eben dynamisch noch Klassen nachladen willst (die als .class vorliegen, nicht als kompiliertes Ding), dann brauchst du gij - der ist extern.

Wie sieht das mit dem Decompilieren von solchen Klassen aus?

Alles was du kompiliert hast ist genau so sicher gegen dekompilieren wie jedes andere Programm was du mit dem GCC kompilierst.
d.h. viel weiter als Assembler kommst du auf Basis von dem nicht - auch wenn ich mal irgendwo schon ein Tool gesehen habe was das ganze zu C - Code macht (allerdings ist der unleserlich wegen der fehlenden Methodennamen und auch sonst taugt das Ding praktisch nicht viel - ausser als Beweis dass man eben noch etwas mehr draus machen kann als nur Assembler...).

MfG Peschmä

[sparrow]

Was ist das denn GCJ bzw. was kommt denn da am Ende raus?
Klingt nach Linux?

[Sym]

Der GCJ ist ein freier Compiler, welcher Maschinencode, class-files oder von class-files in Maschinencode übersetzen kann.

Damit bist Du dann z.B. nicht mehr auf die JVM von Sun angewiesen. Hat mit GNU/Linux halt nur den Zusammenhand, dass es beide Gnu-Projekte sind. Sonst läuft das aber auch unter Windows und OSX.

Am Ende kommt da halt ein Java-Programm raus. Wenn gewünscht, dann eben ein natives.

[peschmae]

Zitat von sparrow

Was ist das denn GCJ bzw. was kommt denn da am Ende raus?
Klingt nach Linux?

Hmm, ich verstosse mal wieder gegen meine eigenen Regeln hier und schreibe nicht was das Ding tut.

Zu dem was Sym geschrieben hat gibts eigentlich nicht mehr viel hinzuzufügen - ich machs trotzdem
GCJ ist ein Teil von GCC. GCC ist der Compiler von Linux - besser gesagt vom GNU Projekt. GCC kann C, C++, Ada, Objective-C (Apple benutzt den auch), Fortran, zeugs, geschichten, nochmehr und auch Java - der Teil davon heisst dann GCJ.

GCJ beinhaltet auch GIJ - einen Interpreter, der Java-Classfiles interpretiert. Kompilieren kann GCJ auch - von *.java sourcen nach binäres Programm, von *.class Dateien nach binäres Programm und so. Netterweise schluckt er auch gleich ganze Jar-Dateien aufs mal

Für Windows gibts das Ding übrigens hier: http://thisiscool.com/gcc_mingw.htm ist aber noch recht eine Bastelei (vermute ich - ist schon über ein Jahr her seit ich den das letzte mal unter Windows benutzt habe)

MfG Peschmä