Ich will jetzt gar keine große Diskussion für oder gegen Java/Cocoa lostreten. Ich habe die Kombination mal getestet, weil sie mir sehr interessant erschien, und bin leider an der schlechten Dokumentation, der fehlenden bzw. mangelhaften Java-Unterstützung von XCode und dem extrem schlechten Roundtrip-Enginnering des Interface Builders gescheitert. Aber vielleicht lag es auch nur an meiner Unfähigkeit...

Entwickelt ihr mit Java, Cocoa und XCode. Also nicht mit Eclipse SWT-Anwendungen o.ä., sondern Cocoa-GUIs mit Java-Backend?
Wenn ja -- warum? Weil ihr Objective C nicht mögt? Oder weil irgendwelche Zusatzbibliotheken in Java vorliegen?
Wenn nein -- habt ihr es mal versucht? Woran hat es bei euch gelegen, dass ihr es aufgegeben habt?

GL
(der mal neugierig ist, ob Java, XCode und Cocoa mehr als nur Marketingsprüche sind)

Variante a)
Du kannst mit Java-Swing Mac-Apps entwickeln, die aussehen und sich verhalten wie alle anderen Mac-Apps inklusive Menübar.

Variante b)
Die Java-Cocoa-Bridge soll den Einstieg für Java-Geeks in Cocoa-Entwicklung ermöglichen. Langfristig sollte dann auf Objective-C (Variante C) umgestiegen werden, wenn man das ernsthaft betreibt.

Variante c)
Reine Entwicklung mit Cocoa (sprich NeXTSTEP) mit Objective-C.

Nachtrag:
Nur Variante a) liefert plattformunabhängigen Code. Der Menübar wird automatisch oben (Mac) oder im Fenster (andere) angezeigt.

Ich entwickle Applikationen crossplatform (Mac/Win/Linux/Unix), aber nicht mit Java/C/C++/XCode...

Weil:
Java: Write once, crawl anywhere

Allerdings ist XCode für den Preis ABSOLUT unschlagbar


Gruß

Klaus

Hm, also ich habe die letzten Jahre mit Java-Entwicklung meine Brötchen verdient und eine längere Zeit davon XCode als IDE verwendet. Ich weiß nicht welche Probleme du hast, mir hat der XCode eigentlich gereicht. Eclipse kann ich nicht ausstehen. Und für Cocoa/ObjC ist XCode sowieso erste Wahl, finde ich.

Mangelhafte Roundtrip-Fähigkeiten vom Interface Builder? Vielleicht machst du da was verkehrt. Ich finde den IB - bis auf ein paar rauhe Stellen - genial gut. Allerdings habe ich nur Erfahrungen mit ObjC und IB, weil wenn Java, dann Swing.

ich hab mal ein java-Cocoa Programm geschrieben. Bis auf die Startzeit ist es nicht von einem Obj-C Programm zu unterscheiden. Solange man keine üblen Interface - Sachen möchte, geht's ganz gut mit Java-Cocoa.

Allerdings spricht für mich mittlerweile nicht mehr viel gegen reines Java (z.B. Swing oder SWT) - jedenfalls für die Wald-und-Wiesen Apps: Plattformunabhängig, super IDE (Eclipse oder Netbeans), GUI-Widgets auf Mac sehr gut umgesetzt sodaß man es von einer nativen Umgebung kaum unterscheiden kann etc.

Außerdem (duck!) hat java die besseren/einfacheren API's als Cocoa - und kann natülrihc auf eine viel breitere Library-Unterstützung bauen.

Einen Interface-Builder vermisst man zwar, aber irgendwann ist die Arbeit am Interface auch durch - und dann ist das Thema nicht so wichtig...

jochen72
Aua Wenn es meiner Ansicht nach etwas gibt, was schlecht an Java ist, dann die Klassenblibliothek (das meinst du doch mit API, oder?). Die Klassenbibliothek leidet an einer Menge Altlasten und an dem später auf die AWT draufgepappten Swing. Es wäre Zeit, endlich mal mit dem eisernen Besen durch die Klassen durchzugehen. Wird halt nicht gemacht, weil es eine Zäsur gäbe.

Jedenfalls bin ich nach der Arbeit mit Java immer wieder froh, wenn ich mich mit den deutlich klareren Cocoa-Frameworks beschäftigen darf Was nicht heißen soll, daß dort alles nur Sonnenschein ist

Es gibt ein neues API für GUI's: SWT. Damit werden die nativen Widgets vom Betriebssystem benutzt - dazu ist es auch noch halbwegs angnehem zu programmieren. (ist von Eclipse)

Das Pendant zur "Foundation" finde ich in Java allerdings sehr viel reichhaltiger - und auch die API ist ganz okay. Nur stellenweise scheinbar von irgendwelchen Informatik-Genies entworfen worden, die den Blick für den realen Einsatz aus dem Auge verloren haben...

jochen72
Habe ich noch nicht ausprobiert. Ändert aber nix an den Altlasten in der Klassenhierarchie.

Ja genau. Nur empfinde ich den Begriff "reichhaltiger" als Euphemismus. Ich liebe halt nun mal schlanke und durchdachte Frameworks

Siehste, das sehe ich genau andersherum. Ich vermute du meinst die Java-Klassenbibliothek? Als ich die das erste Mal gesehen habe, war mein Gedanke: endlich mal eine Klassenbibliothek, die von Leuten geschrieben wurde, die ihren Gamma et al. nicht nur dekorativ im Regal stehen, sondern sogar verstanden haben

Hmm... ich verstehe wirklich nicht, warum man als Java-Entwickler XCode einsetzen sollte. Eclipse ist genauso teuer und für Java einfach um Längen besser als XCode (Code-Completion, Refactoring, Erweiterbar durch Plug-Ins für Webapps, Code-Folding, etc.).
Und wenn ich eine GUI-Bibliothek für Java verwende, dann nicht mehr Swing, sondern SWT bzw. Eclipse RCP. Im übrigen sehen SWT-Anwendungen wesentlich besser aus (hehe, zumindest unter OS X) als Swing-basierte GUIs. Aber das ist wohl Geschmackssache.

Ich weiss nicht, was an der Java API auszusetzen ist. Ich habe schon so manche Bibliotheken für Grundfunktionaolitäten gesehen, und ich finde Java (von mir aus mit Swing) gar nicht so schlecht. Aber in der Praxis verwende ich ohnehin soviele Bibliotheken, dass mir da die reine Java API, also die im JDK enthaltenen Klassen, manchmal eher untergeordnet erscheinen.

Es ging mir auch nicht um Swing/SWT vs. Cocoa. Sondern _nur_ um die Cocoa-Java-Bridge in Kombination mit XCode. Ich selbst bin leider von dieser Kombi maßlos enttäuscht. Beispielsweise finde ich die Umsetzung der Delegator-Methoden sowohl designtechnisch als auch aus Entwicklersicht katastrophal. Dass etwa Funktionen wie "awakeFromNib" nicht über ein Interface deklariert werden, sondern wohl über Relection gefunden werden, ist einfach kein guter Stil. Da ich selbst mit wirklichen vielen Bibliotheken arbeite (bspw. der ganze jakarta-Kram, J2EE, mittlerweile diverse Eclipse Frameworks, evtl. Persistennzframeworks etc.) und ich daher die APIs nicht ale im Kopf haben kann -- das Konzept reicht -- ist für mich Code-Completion eines der Hilfsmittel überhaupt. Und dann kommt da XCode ohne Completion und eine API, bei der das auch nichts nützen würde.

XCode ist für (Objective) C wohl ganz gut, aber für Java hinkt es einfach technologisch ein paar Jahre hinterher.

Nur meine Meinung jetzt: Ich würde an Apples - Stelle KOMPLETT auf Eclipse setzen und die eigene IDE auslaufen lassen. Die 50(?) Entwickler, die für die IDE Erstellung am start sind, könnte man evtl. besser einsetzen.

Zumindest würde ich nicht versuchen, eine state-of-the-art Java-IDE auf den Markt bringen zu wollen. Die gibts schon in aussreichender Zahl...

und die java-Cocoa bridge würde ich durch ein supported Phython - Wrapper (gibts schon) ersetzen, der wiederum mit java sprechen könnte. Dann müsste man glue-code für das gui in python schreiben und könnte seine Geschäftslogik in java machen. Aber eigetnlich brauch man das ja nicht, weil SWT ohnehin schon ganz gut läuft - schliesslich ist carbon ja auch ein "offizielles" APi... etwas wirr bin ich heute vielleicht.

jochen72
Gott sei Dank hört Apple nicht auf Dich. Xcode basiert auf der NeXTSTEP-Entwicklungsumgebung - sprich Objective-C - und stellt damit die Grundlage von Mac OS X dar.

Daß man auch Java mit Xcode programmieren kann, ist nur ein zusätzliches Schmankerl, was in letzter Zeit hinzukam und sicher auch noch verbessert wird. Zweifellos läßt sich mit Xcode am einfachsten eine Mac-like-Application in Java entwickeln, weil Xcode den Java-Code, der für das Mac Look & Feel nötig ist, als Gerüst bereitstellt.

Achso, Code-completion. Naja, verwende ich nicht, benutze nur Text-completion, so wie es z.B. im Emacs ist. Refactoring halte ich für Humbug und nur gut für Leute, die erst coden und dann denken.

Was an der Klassenhierarchie von Java schlecht ist? Nur mal ein paar Beispiele: Point ist nicht die abstrakte Basisklasse, wie man vermuten würde, sondern leitet sich von Point2D ab. Manche Methoden wollen Point, andere wollen Point2D. Manche Klassen sind in der Hierarchie an Stellen, wo sie nicht hingehören (teilweise das AWT-Zeugs). Zuviel deprecated-Zeugs (Altlasten). Für meinen Geschmack zu wenige Fassaden-Klassen. Die Swing-Layoutmanager sind kacke (hatte mir daher zwei neue geschrieben, das hat den GUI-Source locker halbiert). Da meine Java-Zeit nun schon einige Monate zurückliegt, ist mir das meiste wieder entfallen

Ich bin halt Purist und nicht an einer Lösung interessiert, sondern an der schönsten.

jochen72 Hehe... das mit Python muss von mir aus nicht sein, aber XCode mit Eclipse zu ersetzen fände ich auch sinnvoll. Dann wird für Objective C, dem Interace Builder und Cocoa etc. ein oder mehere nette Plug-Ins gebastelt und fertig. Jipp!

MacMark Das XCode auf der NextStep-IDE basiert ist doch kein Grund, es nicht aufzugeben, oder?

Gilderoy Lockhart
Du machst Deinem Namens-Vettern aus Harry Potter alle Ehre.

Womit - glaubst Du - schreibt Apple Mac OS X, was aus Objective-C besteht? Na, na, na?

MacMark

Naja, nicht jeder Hersteller muss eine eigene Entwicklungsumgebung für seine Software haben, oder? Z.B. Adobe hat ja auch keine IDE...

Die Kronjuwelen von NextStep sind vor allem Cocoa und Interface-Builder (ok und Webobjects). Das könnte ja ruhig alles bleiben...

Für alle die konsistente und schöne Aqua-Oberflächen mit Swing erstellen wollen, lohnt sich sicherlich mal ein Blick auf nib4j Damit klappt das Oberflächendesign (denke ich) ganz gut.