Hat vielleicht schon jemad ein fertiges build/binary von GCJ (GNU Java Compiler) für OS X zur Verfügung?
<br>
<br>Ich möchte das Zeug nicht gerade tagelang konfigurieren und übersetzen...

Warum nimmst Du nicht den mitgelieferten Java-Compiler per Terminal oder Xcode?

wo ist der Vorteil dieses Compilers?

Der Vorteil vom GCJ ist, daß er wahlweise keinen Bytecode erzeugt, sondern nativen Maschinencode.

MacMark<br>
<br>Ich möchte aus eine Java Bibliothek eine native Bibliothek bauen, die in in ein anderes Projekt einfügen kann.
<br>
<br>Konkret benötige ich eine dylib. Könnte dafür einen C wrapper für den Java source schreiben, aber GCJ ist möglicherweise einfacher - möglicherweise. Weiss aber noch nicht, ob so etwas überhaupt geht...

Rantanplan<br>
<br>Hast Du schon Erfahrungen damit? Ist das Teil ok und läuft dann wirklich?
<br>
<br>Hm, sollte ja wohl gehen, da der GCJ auf Java über C++ dann ein binary baut - soweit ich weiss.

Stefan Pantke [turingart-CUBiC GmbH]<br>
<br>Eine aktuelle Version habe ich nicht probiert. Vor ein, zwei Jahren habe ich mir mal eine x86-Linux-Version besorgt und ein größeres Projekt damit versucht zu kompilieren. Hat damals nicht funktioniert. Was mich nicht gestört hat, da ich eigentlich nur sehen wollte, ob es einen deutlichen Performance-Unterschied gibt. Seitdem habe ich mich um GCJ nie mehr gekümmert.

Rantanplan<br>
<br>Ich berichte dann später mal, wie das Teil läuft. Üersetzung scheint recht einfach zu sein, siehe: http://users.bestweb.net/~john3g/gcj_osx/gcj_on_osx.html
<br>
<br>

Man kann mit Hilfe von Xcode Java-Programme schreiben und die dann nativ für OS X kompilieren lassen. Das sind die sogenannten "Cocoa-Java-Applikationen". Die so erzeugten Apps sind reine Cocoa-Apps und nicht mehr Java, obwohl der Quellcode Java war. Möglich macht das die Java-Bridge von Xcode.
<br>Man kann natürlich auch normale Java-Apps mit Xcode schreiben, die dann die Java Virtual Machine nutzen, aber das ist eine andere Rubrik in Xcode.
<br>
<br>Buch macht kluch

Stefan
<br>
<br>Kennst du die Anleitung hier schon? http://users.bestweb.net/~john3g/gcj_osx/gcj_on_osx.html

Stefan
<br>
<br>ROFL.... Da haben wir die gleiche Seite gefunden

MacMark<br>
<br>Bist Du da ganz sicher? Ist es nicht so dass der ByteCode in the fertige Applikation gemischt und dann on-the-fly ausgeführt wird?
<br>
<br>Link zu Dev@Apple wäre interessant. Habe ich spontan nicht gefunden...
<br>

Stefan Pantke [turingart-CUBiC GmbH]<br>mache doch einfach in XCode ein neues Projekt vom Typ Cocoa-Java Application und baue das. Dann dürfte das Ergebnis doch aussagekräftig genug sein, um herauszufinden, ob es nun ein Java oder Cocoa Programm geworden ist.

Ne ne, XCode erzeugt aus Java keinen nativen Code. Die Java-Bridge ist nur eine API, sonst nix. Wenn ihr es nicht glaubt: erzeugt mal so ein Projekt, und kuckt im Bundle unter Contents/Resources/Java, dort findet ihr das jar-File mit den kompilierten Klassen

Rantanplan<br>
<br>Na, dann habe ich mich doch richtig erinnert an den Artikel, in dem der Autor schrieb, dass die Java-Bridge recht beeindruckend ist...
<br>
<br>BTW: Die ersten beiden compiler sind fertig. Dauert jetzt vermutlich noch 2-3 Stunden. Ich werde das Ergebnis per FTP auf den turingart Server legen, so dass nicht jeder immer wieder bei NIL starten muss. Das Ding scheint auch für den einen oder anderen Entwickler interessant zu sein...

Update: GCJ scheint wirklich zu fuktionieren. Es wandelt gerade die Java Standard-Bibliotheken in binary code um.
<br>
<br>Übrigens sind nicht nur Anwendung übersetzbar, die kein UI haben, sondern auch AWT, SWT und SWING.

wie der Performanceunterschied so ist, wuerde mich auch sehr interessieren...

Rantanplan<br>
<br>Ich glaube Du warst im falschen Projekttyp. Die fertige .app sollte rein Cocoa sein.

ich habe das gerade mal gemacht, und das Ergebnis ist auf dem Bild zu sehen. Rantanplan hat recht mit der Java Bridge, denn in den Ressourcen liegt das .jar File. Also ist das kein reines Cocoa Programm.
<br>Ausserdem hat das main File die Endung ".m". Was sagt uns das? Ganz einfach: ObjectiveC.

Compilier es und schau Dir die ausführbare Application an.

KillBill<br>
<br>soweit ich gehört habe, gar kein so grosser unterschied zur VM. Die performance wird grundsätzlich etwsa anders sein, da die GNU leute einen anderen garbage-collector verwenden.
<br>
<br>BTW: Hat übrigens schlappe 8 Stunden gedauert, das Teil zu bauen...
<br>
<br>Übrigens kann GCJ *.java und *.class Dateien compilieren und wir ausserdem noch mit einem eigenene bytecode interpreter geliefert, so dass native code und compiled code gemixt verwendet werden können.

MacMark<br>
<br>Ich setz ne Kiste Bier drauf, dass der JAVA Code nicht compiliert wird.

MacMark<br>das ist der Bundle-Inhalt der compilierten Anwendung.

Hier ist nun die binary distriburtion von gjc: http://idisk.mac.com/seaside.ki/Public/gcj.zip
<br>
<br>Grösse: ca. 45 MB
<br>Zielfolder: /usr/local/gcj [und NUR hier]
<br>System: Panther 10.3.7 [vermutlich auch andere Systeme]
<br>
<br>Die Distribution enthält neben dem C-Compiler noch einige andere Compiler, die auf alle Fälle erforderlich sind. Es handelt sich um einen gebootstrapten gcj, also die sichere Variante, die sich selber compiliert und geprüft hat.
<br>
<br>Fragen: PM oder hier
<br>

Hallo alle miteinander!
<br>
<br>Mein erster Post in diesem Forum *freu*
<br>
<br>Und natürlich gleich eine Frage.
<br>@Stefan
<br> Hast du schon einmal versucht ein mit swt programmiertes Programm mit Hilfe vom gjc zu kompilieren?
<br>Schreiben tu ich meine Programme mit Eclipse, habe aber auch den gjc am Laufen, welches ein einfaches "Hallo Welt" auch schön brav kompiliert. Meine swt Prograamme dagegen mag er nicht.
<br>
<br>LG
<br> Daniel

ddaniel soweit ich weiss, gibt es die (plattformabhängige!) SWT-Implementierung noch nicht für den Mac.
<br>
<br>Oder gibts da schon was neues?

Um hier mal aufzuklären.
<br>
<br>1. Der gcj erzeugt lediglich TextProgramme. Das ganze AWT und Swing-Zeugs ist da nicht drin.
<br>
<br>2. Hier braucht sich keiner Einzubilden nur weil es Maschinencode ist, ser der gcj schneller. Auch die normale JVM hat einen JustInTime-Compiler eingebaut. Das langt für die meisten Anwendungen. Macht sich natürlich bei nur wenigen Schleifendurchläufen nicht bemerkbar.
<br>
<br>Wir haben hier Kunden die berechnen ihren Finite-Elemente Kram in Java. Und über Geschwindigkeit hat sich noch keiner beschwert.
<br>
<br>Das wichtigste bei Java ist einfach nur RAM. Dann geht das schon ordentlich ab.
<br>
<br>

Die CocoaJavaBridge bietet Java-Wrapperklassen, die intern auf vorhandene Cocoa-Objective-C-Klassen zugreifen. Insofern wird die Java Virtual Machine für diese Hüll-Klassen notwendig sein. Die resultierende Cocoa-Applikation ist trotzdem keine Java-Applikation.
<br>Die Java-APIs werden bei dieser speziellen Programmart auf entsprechende Objective-C Interfaces abgebildet.
<br>Man kann die CocoaJavaBridge auch ohne Xcode nutzen. Diese Programmierungsart ist für Java-Enwickler, die Objective-C nicht kennen. Man nutzt den Interface Builder für die Programmoberfläche. Es werden dann auch die typischen NIB-Dateien (NeXTSTEP Interface Builder) angelegt. Cool sind auch die ganzen NS*-Klassen. Die Benennung wurde aus Kompatibilitätsgründen beibehalten, denn der Vorgänger von Cocoa war das berühmte NeXTSTEP (NS).
<br>
<br>Quellen:
<br>Mac OS X Panther in a nutshell, Seite 427
<br>Java für Mac OS X, S. 330-340

Frank<br>
<br>Habe ich ja schon vorher so geschrieben. In der Tat geht es mir selber auch gar nicht um Performance.

bloede Frage, aber was macht es dann einen Sinn das in Maschinencode zu compilieren, wenn man keine zusaetzliche Performance hat...man verliert doch nur die Portabilitaet...ich sehe dann keinen Vorteil mehr...oder habe ich was uebersehen?

KillBill<br>
<br>Ich hätte gerne eine native Bibliothek, um sie aus einem anderen Programm direkt aufrufen zu können. Der Zugriff auf Java Code ist - soweit ich weiss - ewtas komplizierter, wenn der Code in einer dylib liegt. Kann aber auch total falsch liegen...
<br>
<br>Übrigens wird der Programmstart stark beschleunigt. Und natürlich ist auch keine JVM erforderlich, um Code auszuführen. GCJ kann aber trotzdem auch *.class Dateien ausführen, da ein bytecode interpreter integriert ist.

ddaniel<br>
<br>Diese Seite könnte für Dich von Interesse sein: http://users.bestweb.net/~john3g/gcj_osx/gcj_on_osx_gui.html
<br>
<br>Ich selber habe noch keine apps mit UI per gjc compiliert - habe zu Zeit noch Probleme überhaupt irgendwelche Programm die mehr als ein File enthalten z übersetzen. Längere Zeit nicht mehr gemacht...

Frank<br>
<br>Die Performance von Java mit JIT-Compiler ist phantastisch, da fällt mir kein anderes Attribut ein. Der Artikel war zwar etwas umstritten, aber in der c&rsquo;t hat mal jemand einen Benchmark zwischen C#, Java und C++ gemacht. Das C# lag mit Java ziemlich gleichauf, kein Wunder, ist es ja nur eine geklaute Java-Variante und verwendet die gleiche (VM-)Technik. Lustig war aber, daß Java teilweise schneller ausgeführt wurde als das was der C++-Compiler erzeugt hat. Ob&rsquo;s wirklich stimmt oder der Autor des Artikels zu tief ins Glas gekuckt hatte, keine Ahnung, aber Java ist meiner Erfahrung nach wirklich performant. Solange..... solange man kein Swing verwendet

Rantanplan<br>
<br>Ich habe vor einiger Zeit begonnen einen Prototyp einer Anwendung mit SWING zu bauen. Das Tool sollte auch auf älteren Systemen laufen - da Kunden so etwas hat noch haben..
<br>
<br>Habe es eingestellt, da die Performance so EXTERM mies war, dass wir MINUTEN auf eine Reaktion auf Clicks warten mussten.
<br>
<br>Sind dann auf REALbasic umgestiegen, was ja auch crossplatform arbeitet und ordentliche OO Programmierung erlaubt - und auf urarlten Gurken noch funktioniert. Und das gilt selbst bei einer Grafik-lastigen Anwendung...
<br>
<br>Cocoa ist schöner, aber RB ist teilweise wesentlich schneller in der Enwicklung. Natürlich hat RB auch seine Probleme und Macken...

… 64 KB Hauptspeicher sind halt nicht mehr ausreichend …

Rantanplan: Gibt es den Test den Du beschreibst online? Das würde mich interessieren. Ich mache recht viel in Java und finde die JVM von OS X viel zu langsam. Mir scheint die JVM unter einem Win System schneller.
<br>
<br>(Ich glaube es wurde oft genugt gesagt, aber CocoaJavaApps ist normaler Java Code der in der JVM läuft. Das Cocoa-Mässige daran ist, dass man Cocoa Funktionalität von Java aus aufrufen kann. Die läuft dann natürlich nativ - wie ein JNI Call. Wird sicher auch über JNI realisier.)
<br>
<br>Ich finde z.B. Eclipse auf dem Mac subjektiv langsamer als unter Win, aber das kann auch am Plattformabhängigen SWT liegen.
<br>
<br>

Christian Fries<br>
<br>Bestätigt! Auf einem 2 Jahre alten PC mach Eclipse Spass, auf einem 1 Jahr alten Mac leider nicht - wenngleich der Mac natürlich sonst VIEL besser ist.

MacMark<br>
<br>Nee, leider viel schlimmer: Auf einem Toshiba Notebook mit 400 MB aber eben keinem aktuellen P4 lief das System extrem langsam. Auf einem P4@1,7GHz lief es problemlos und schnell.
<br>
<br>Nur leider habe mittelständige Unternehmen nicht die neuesten PCs. Und da die Software nun mal nicht für mich ist sondern für Menschen, die dafür bezahlen sollen, ist bei Business Software eine Mindestperformance und eine Abstimmung auf ältere Hardware sehr wichtig.
<br>
<br>Bei einem Unternehmen im Finance Bereich, bei dem Java vermutlich als Strategie gesetzt ist und neuere Hardware eher normal ist, wäre es natürlich kein Problem gewesen.
<br>
<br>Wie auch immer: Mit RB läuft die Anwendung einfach schnell, kann auf dem Mac entwickelt und (auch) für Windows ausgeliefert werden. Zudem sind auf jeder Plattform auch native Calls möglich.

The Java Version of Cocoa
<br>developer.apple.com/documentation/Cocoa/Conceptual/CocoaObjects/Articles/JavaCocoa.html

The Java Version of Cocoa
<br>http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaObjects/Articles/JavaCocoa.html
<br>
<br>This blue ball replacement feature sucks big time!

MacMark<br>
<br>Und? Da steht doch nur, dass die bridge transparent Objekte abbilden kann. In dem Artikel steht nicht, dass Java in ObjC oder umgekehrt compiliert wird. Und das habe ich auch noch nicht gehört.
<br>
<br>Die Apple Jungs sind einfach stolz darauf, dass Sie - vermutlich mit Hilfe von Introspection - zwischen der Java und der ObjC Welt hin und her wandern können.
<br>
<br>Oder wolltest Du was anderes sagen?
<br>
<br>
<br>

Wenn man Wrapperklassen nutzt, wie es die Bridge macht, die - einfach ausgedrückt - außen Java und innen Objective-C sind, dann muß dort überhaupt nichts von der einen in die andere Sprache rübercompiliert werden. Weiterleitung würde den Vorgang treffender beschreiben. Das ist doch viel eleganter als rübercompilieren.

Christian Fries<br>
<br>Online nicht, aber ich kann dir den Verweis dazu liefern:
<br>
<br>Arne Schäpers, Rudolf Huttary
<br>C#, Java, C++ und Delphi im Effizienztest, Teil 1
<br>c&rsquo;t 19/03, Seite 204
<br>
<br>C#, Java, C++ und Delphi im Effizienztest, Teil 2
<br>c&rsquo;t 21/03, Seite 222
<br>
<br>Früher habe ich den Arne Schäpers gerne gelesen, als er noch in den Eingeweiden von Turbo Pascal herumkramte. Jetzt - muß wohl am Alter liegen - macht er nur noch mit .Net und C# rum. Traurig, wie tief manche fallen können

Christian Fries<br>
<br>Ja. Mir auch. Und zwar bereits ohne GUI. Mein Verdacht ist, daß der JIT-Compiler bei der Apple-Java-VM wenig taugt.

@MacMark: Cocoa ist ein API. Die Cocoa Funktionalitäten sind zwar in Objective-C geschrieben, aber sie liegen als PowerPC Maschinencode vor. Wenn Du Cocoa Funktionalität aus Objective-C aufrufst wird der gleiche Maschinencode ausgeführt wir wenn Du Cocoa Funktionalität über die Java Bridge aufrufst. Dieser wird natürlich ausserhalb der Virtual Maschine ausgeführt - das bestreitet hier niemand.
<br>
<br>Das ist das Prinzip von JNI - Java Native Interface. Nur: Wenn Du "Java Version of Cocoa" machst, dann braucht der Java Code der das Cocoa API nutzt eine Virtual Maschine, d.h. der Code den Du noch schreibst läuft in der JVM.
<br>
<br>Mit GJC braucht aber auch der keine JVM mehr - so habe ich das hier verstanden. Und nur darum geht es.
<br>
<br>Stell Dir vor Stefan Pantke wollte Java Code schreiben und gar keine Cocoa Funktionalität nutzen... dann ist sein Frage nach GJC auf OS X ebenso berechtigt.
<br>
<br>Comments anyone?
<br>

Christian Fries
<br><br>
<br>Richtig vestanden. GCJ übersetzt Java über die Zwischensprache C++ in Maschinencode. Allerdings steht eine JVM zur Verfügung, falls dann doch noch mal bytecode interpretiert werden muss - vermutlich wenn ein JAR zur Laufzeit geladen wird.
<br>
<br><br>
<br>Stimmt genau, ich will in diesem Fall gar nichts mit Cocoa machen. Habe hier eine reine Java lib rumliegen...
<br>

Stefan Pantke: Danke für die Comments. Ich hatte mich nämlich gewundert was bei einem Aufruf des Class-Loaders geschiet. Ob die GCJ Runtime dann einen ByteCode-2-NativeCode Compiler anwirft oder eine JVM integriert hat...
<br>