Alte Versionen, die vor Sicherheitslücken strotzen. Browser, die wegen dieser Sicherheitslücken Java gleich deaktivieren. Software, die mit neuen Java Versionen nicht läuft und deretwegen man das alte, unsichere Zeugs verwenden muss ...
Was geht mit Java (einfacher) was ansonsten nicht zu machen wäre? Als Anwender und als Admin, der sich mit Firmen herumschlagen muss, die Java verwenden, kommt es mir manchmal einfach nur als Faulheit vor "was Vernünftiges" zu programmieren. Ich lasse mich aber auch gerne eines Besseren belehren.

ExMacRabbitPro: Nee, das hab ich ja eben auch schon geschrieben. Das war ja auch immer mein Punkt.

Ich hab mir CPA nochmal ganz kurz angesehen. Da hat sich ja echt was getan. Als ich mir es zuletzt angesehen konnte ich nicht mal Livedaten ansehen, sondern nur erst Aufzeichnen und dann ansehen.

Ich bis seit fast 25 Jahren Softwareentwickler und habe so ziemlich jede in der Zeit populäre Sprache auf jeder Plattform benutzt und in entsprechenden Projekten gearbeitet.

Meine Erfahrung: Schlechte Programmierer schreiben schlechte Programme, gute Programmierer schreiben gute Programme. Und zwar unabhängig davon, in welcher Sprache, mit welchem Framework, unter welchem OS und auf welcher Plattform.
Wenn man sich nur blöd genug anstellt, kann man jedes noch so geniale System verhunzen.

Auch eine Plattformunabhängige Software kann so geschrieben sein, dass sie auf den Plattformen auf denen sie eingesetzt wird nicht wie ein Alien wirkt. Aber dazu muss der Entwickler das nötige Gespür haben und den Ehrgeiz. Leider haben das nicht viele.

Das ist mitunter der Grund, warum Java Programme so einen schlechten Ruf haben. Nicht weil Java schlecht wäre, sondern weil viele Entwickler Flaschen sind und keinen Bock haben, eine brauchbare Arbeit abzuliefern. Moto: "Wenn es funktioniert ist es für mich ok". Aber wie es mit der Usabiliy aussieht, das ist dann ein anderes Thema.

Just my 3 cents....

Es ist ein Paradigma für Branchenlösungen. Es gibt für solche Software nur wenige Nutzer, der Kostenfaktor ist dann der wichtigste Faktor. Da WireShark OSS ist, ist es der Arbeitsaufwand die Software zu portieren in Relation zu den wenigen Mehrnutzern. Wer Wireshark als Applikation braucht, dürfte in der Lage sein mit einem GTK+ Interface zurechtzukommen.

Ich habe diesen Dogmatismus nie geteilt, daß nur "native" Interfaces gute Interfaces seien. Wichtiger war und ist immer noch die Programmlogik selbst. D.h. wenn das Interface zwar toll ist, aber das Programm die eigentliche Aufgabe nicht hinreichend gut löst, ist es vollkommen wertlos.
Es ist einer der Sachzwänge des Lebens. Wenn du Selbstausbeutung als Lebensmotto für akzeptabel hältst, dann trifft dies noch lange nicht auf den Rest der Menschheit zu. Eine angemessene Bezahlung gehört zur Arbeit dazu.
Crossplattform Software ist nicht automatisch unergonomische Software. Wenn man die meiste Zeit innerhalb einer Applikation arbeitet, ist es relativ egal, wie gut sie in das OS integriert ist. Wichtig ist nur die innere Logik und klare Bedienbarkeit. Insbesondere bei Branchenlösungen wissen viele Nutzer der Software gar nicht mit einem Computer direkt mit dem OS zu interagieren. Davon sind ist meist überfordert. Da zählt nur die Schulung auf die eigentliche Applikation.

Eine möglichst portable Software, die sich dann unter jedem OS möglichst gleich bedienen läßt, ist dann für den Kunden sogar von Vorteil, weil er dann leicht das OS wechseln kann und nicht von teuren Schulungen abhängig ist. Schulungen sind dann nur notwendig, wenn sich etwas an der Applikation selbst ändert.

Wobei hier der Trend ganz klar hin zu Weblösen geht, und das meistens auf Basis von JavaEE. Diese sind dann natürlich nicht in OSX integriert, weil das bei WebUIs nie der Fall ist.

Ist es in dieser verallgemeinerten Form eben nicht.

Ein Sachzwang ist es nur, solange Du oder die Mitarbeiter einer Firma andernfalls verhungern oder erfrieren würden. Und da Programmierer zu den gesellschaftlich Privilegierten gehören, die sich schon dumm anstellen müssen, damit es nicht für mehr als das Existenzminimum reicht, ist hier weit und breit kein Sachzwang zu sehen.

Es ist Deine Entscheidung, wenn maximierter materieller Wohlstand Dein Ziel ist. Nichts und niemand zwingt Dich dazu.
Und hier es wieder, das Dogma, und auch noch gleich doppelt:

• „Du magst als einzige Ausnahme das skurrilerweise ja anders halten, aber ich repräsentiere mit meiner Einstellung die gesamte Menschheit (außer Dir), daher ist meine Einstellung gar kein Dogma, sondern schlichte Realität.“
• „Finanzieller Ertrag ist der einzige mögliche Gewinn, der Verzicht darauf ist daher logisch zwingend Selbstausbeutung.“ – Was aber, wenn meine Genugtuung über eine kompromisslos gute gelungene Arbeit mir weit mehr Lustgewinn verschafft als monetäre Vorteile? Wenn ich diese Art von Lustgewinn mit keinem Geld der Welt kaufen könnte? Wieso beute ich mich dann selbst aus, wenn ich meine Lust maximiere?

• Mag sein, ist aber aus meiner Sicht bei weitem nicht das Wichtigste.
• Was ist „angemessen“? Die Millionengewinne, die manche Softwarehersteller abschöpfen, die sich „leider nicht in der Lage sehen“, Cocoa-GUIs für ihre Mac-Programme anzubieten (ohne die Kosten dafür auf die Kunden abzuwälzen …)?

Für genau diesen einen Fall – der Anwender als armes Würstchen, das tagein, tagaus nur innerhalb einer Applikation arbeitet (BTW, das wäre für mich Selbstausbeutung!) – hast Du Recht.

Nur: warum sollte so jemand überhaupt Macs verwenden, die teurer sind als hardwaremäßig vergleichbare PCs, deren Mehrwert in Form von Mac OS X er aber gar nicht ausnutzen kann, weil er das Betriebssystem eh kaum bemerkt?

Ein konkreter Ausfluss von Steve Jobs' Ideal, die Kreativität der Menschen zu befördern, war von Beginn des Mac an die Interoperabilität zwischen Programmen, die Anwendern erlaubte, kreativ zwischen Applikationen hin- und herzujonglieren, statt sich in von einzelnen Programmen vorgegebene Schemata pressen zu lassen.

Beim klassischen Mac war das vor allem die strikt gleiche Bedienbarkeit aller Programme (und natürlich Copy&Paste), bei Mac OS X wurde dieser Ansatz extrem erweitert durch zahllose applikationsübergreifende Dienste (gemeinsame Rechtschreibprüfung, gemeinsame Font- und Farbkategorisierungen etc. etc.) und die Allgegenwärtigkeit von Drag&Drop.

Als Anwender wechsle ich persönlich auf Mac OS X stetig zwischen (buchstäblich) mehr als 100 Programmen hin und her. Das wäre völlig unmöglich, wenn jedes Programm seine Idiosynkrasien zur Bedienung mitbrächte. Daher fliegen bei mir wo irgend möglich alle Programme von der Festplatte, die sich nicht strikt in Mac OS X integrieren, denn sie würgen diese Form der Kreativität ab. Da hilft es auch nichts, dass ein Programm isoliert für sich betrachtet vielleicht leistungsfähiger ist als sein Cocoa-Pendant; im Gesamtzusammenhang verschlechtert es das Arbeitsergebnis.

Programme, die sich teils auch noch damit brüsten, auf allen Plattformen gleich bedienbar zu sein, desavouieren diese Kernqualität von Mac OS X und sind aus meiner Sicht daher wirklich von Übel.

schöner Thread, Danke!

Aber nur für sich alleine gesehen. Und auf wen trifft das wirklich zu? Ich habe mit solchen Programmen zu tun (unter Windows), die sich überhaupt nicht an die "Windows-Bedienung" halten. Und ich versichere Dir: Es ist ein Graus. Selbst die MS-eigenen Admintools unterscheiden sich ja schon stark. Aber es gibt da Software. Meine Güte. Die haben nicht umsonst einen Spitzenplatz bei Dreckstool.de inne.

Privat versuche ich solche Programme wie immer es möglich ist zu vermeiden. Es nervt einfach. Das ist vor allem bei Dateiausahlboxen schlimm. Das bei manchen sogar so, daß man die ganze versteckte Unixstruktur sehe und ich mich manuell zum Benutzerordner durchhangeln muß. Die zu bearbeitende Datei einfach in das Fenster ziehen, daß er diese Datei auswählt geht schon gar nicht.

Wenn das betreffende Programm ein ganz spezielles wäre (also eines, mitdem ich eben genau in dieser versteckten Dateistruktur rumwühlen will/muss), dann wäre da ja ok. Ist es aber oft nicht. Also weg damit und nach einer Alternative gesucht, die weniger nervt.

Präziser formuliert müsste es heißen:

„[…] aber ich repräsentiere mit meiner Einstellung die gesamte Menschheit (außer Dir), daher ist die Verabsolutierung meiner Einstellung gar kein Dogma, sondern schlichter Realitätssinn.“

Kann man hier ja immer nicht korrigieren …

Doch genau das ist der Fall. Man kann sich Altruismus erst dann leisten, wenn man ausreichend Geld eingenommen hat. Vorher steht das nicht zur Debatte. Es scheint dir irgend wie bekannt zu sein, aber aus vollkommen unsinnigen Gründen, scheint dir der Aspekt, daß man zuerst seine eigene Existenz absichern muß, als untergeordnetes Ziel zu erscheinen. Da lebt jemand im Elfenbeinturm.
Dieser Trend ist verstärkt zu sehen, Macs werden immer weniger als Arbeitsplattform gekauft, sondern als Lifestyle Produkt.Der Mac hat den Desktop revolutioniert als Jobs nicht mehr in der Firma war. Die DTP Revolution wäre mit Jobs nicht mögloch gewesen, weil er immer nur so unsinniges AIO Konzept verfolgt hat. Die Mac II Serie wäre mit ihm kaum möglich gewesen, aber genau die war für den großen Erfolg des Macs verantwortlich.Das war nie ein Alleinstellungsmerkmal vom Mac System. Die StyleGuides für Motif Applikationen waren zum Beispiel noch restriktiver. Die wohl beste Umsetzung eines Desktops mit Motif gab es von SGI. Wer IRIS Magic noch kennt, weiß was er daran hatte. Viele der IRIS Magic Ideen wurden dann von OS X aufgenommen.
Was für eine kleingeistige Einstellung. Wichtig sind Programme, die mir wesentliche Arbeit abnehmen. Ein Beispiel: Ich nutze zum Schreiben der Dokumentation einen XML graphischen Editor, der in Java geschrieben ist. Er erleichtert die Arbeit enorm, da er es erlaubt direkt Objekte einzugeben, und nicht alles im Texteditor eingeben zu müssen. Ich brauche also nicht die komplette DTD im Kopf zu haben und zu wissen, wann ich welche Tags verwenden darf. Darüber wacht das Programm. Für OSX gibt es keine vergleichbaren Programme, da ist wie zu emacs Zeiten Handarbeit angesagt, d.h. kein graphischer Editor.

Was behindert da die Kreativität mehr?

Windows ist schon sehr speziell. Ich bezog mich eigentlich darauf, daß es

• Programme gibt, die zwar mit unterschiedlichen Toolkits geschrieben wurden, sich aber strikt an die Vorgaben des jeweiligen Toolkits halten.
• Und wenn die Funktionen des Toolkits nicht mehr ausreichen, man dann darüber hinausgehende Funktionen selbst implementiert. Meine Erfahrung ist es, daß viele komplexere Programme eben nicht mit der Funktionalität der Toolkits selbst umgesetzt werden können.

Für den Anwender hat Java nur Nachteile:
Starke Inkompatibilitäten zwischen den Versionen.
Keine native Unterstützung des Systems.

Vorteil für den Anwender:
Es gibt dank Java Software die es sonst nicht für sein System gegeben hätte, weil der Entwickler sich scheut nativ zu entwickeln, warum auch immer.

• Meine Verneinung bezieht sich, wie ich schrieb, auf die verallgemeinerte Form des Arguments, also, dass finanzieller Ertrag stets ein Sachzwang ist, auch dann, wenn man bereits zu Essen und ein Dach über dem Kopf hat. Da das aber jeder Programmierer in Deutschland haben dürfte, ist es m.E. hierzulande praktisch nie ein Sachzwang.
• Wer redet von Altruismus? Ich jedenfalls nicht. Ich rede von Lustgewinn. Und es bereitet mir weit mehr Lust, kompromisslos gute Programme zu schreiben als möglichst viel Geld zu verdienen.

Die Frage ist, was ist „ausreichend“, wann ist denn Dein Leben aus Deiner Sicht abgesichert genug, dass auch etwas anderes als Absicherung zur Debatte steht?

So wie Du redest, macht das auf mich den Eindruck, dass die Latte dafür bei Dir sehr hoch liegt.

Das ist eine mögliche Entscheidung, man kann ein großes Maß an Sicherheit wichtig finden. Aber das ist Deine eigene Entscheidung, kein Sachzwang.

Mir ist Sicherheit weitgehend gleichgültig. Ich habe schon zu viele Biographien erlebt, wo Menschen sich nach allen Regeln der Kunst abgesichert hatten, und dann kam der eine Schicksalsschlag, mit dem sie nicht gerechnet hatten oder gegen den keine Absicherung möglich ist, und sie standen vor dem Nichts. Und hatten nichtmal vorher richtig gelebt, weil sie ja unentwegt mit Absichern beschäftigt waren.

Wenn bei mir morgen alles zusammenbricht, habe ich wenigstens schon lauter Dinge getan, die ich gut und wichtig finde, und niemals gegen meine Überzeugungen gehandelt. Das kann mir dann nichts und niemand mehr nehmen.

Auch das ist eine mögliche Entscheidung, es ist meine, und ich fände es nett, wenn Du die nicht als „vollkommen unsinnig“ brandmarken würdest. Akzeptiere einfach, dass man sein Leben nach verschiedenen Wertskalen ausrichten kann und setze Deine nicht absolut.
Mag ja sein, dass das aus Deiner Sicht ein Elfenbeinturm ist, aber ich lebe schon sehr lange und gut an diesem Ort, also bin ich doch wohl der „lebende“ Beweis, dass das eben auch geht. (Und nein, ich habe kein Vermögen im Hintergrund o.ä.)
Da haben wir sehr unterschiedliche Einschätzungen. Die entscheidenden Weichen hat nach meiner Überzeugung Jobs gestellt. Nicht-AIO-Konzepte gab's bei PCs schließlich zuhauf, das war ja nun gerade nicht das Alleinstellungsmerkmal des Mac (auch nicht des Mac II).
Sorry, aber schon ein Blick auf den Kalender zeigt, dass der Magic-Desktop ein Abklatsch von NEXTSTEP war, nicht etwa umgekehrt (OS X = NEXTSTEP). Und wie rigide die Style Guides bei Motif auch immer gewesen sein mögen, an die Integration von NEXTSTEP kamen sie bei weitem nicht heran.
Danke.

Der Drang nach Perfektion und intellektueller Schönheit als Kleingeisterei, Nutzenmaximierung als breiter Horizont. Auch mal was Neues …

Ist es so schwer, andere Herangehensweisen ans Leben gelten zu lassen?
Schwer zu entscheiden, beides schrecklich.

Ich persönlich würde weder das eine noch das andere machen, da ich Texte nur WYSIWIG verfassen mag. Wenn ich sowas verfassen müsste, würde ich mir lieber erst einen Cocoa-Editor für das benötigte XML basteln.

Lassen wir den Punkt offen, da es ohnehin unterschiedliche Ansichten gibt.
Das AIO Konzept hat aber niemanden wirklich interessiert.
Die DTP Revolution ist fest mit dem MacII, ColorQuickDraw und dem LaserWriter verbunden. Alles erschien erst als Jobs nicht mehr in der Firma war, und widersprach sehr stark dem AIO Gedanken. Denn nur durch Aufbrechen des AIO Konzeptes konnte die DTP Revolution losgetreten werden, denn es bedurfte großer Monitore, auf denen man ganze Seiten sehen konnte, und diese ließen sich nur mit großen FrameBuffer betreiben. Kurze Zeit später gab es dann die ersten 2D Grafikkarten für den MacII.
Es wäre schön, wenn man sich wenigsten vorher über solche einfachen Dinge informieren würde. Der IRIS Magic Desktop erschiend zuerst mit IRIX 3 und lief auf einem IRIS System von SGI. Datum: 6.10.1988. Einen Preview gab's meines Wissens zwei Jahre vorher.
Die erste öffentliche Vorführung von NEXTSTEP 0.8 war am 12.10.1988.

Um diesen Aspekt geht's mir aber gar nicht. SGI hat schon sehr früh schon so Dinge wie skalierbare Icons, und konsequente 3D Unterstützung in den FrameWorks gehabt. SGIs GL wurde dann später bereinigt und als OpenGL veröffentlicht (PHIGS wurde damit ausgehebelt). NeXT hat zu keinem Zeitpunkt eine Workstation mit 3D Hardware angeboten. Die NeXTdimension im Cube war eine reine 2D Color Karte, der Rest hatte ohnehin nur FrameBuffer im System. Skalierbare Icons gab's erst mit OS X. Auf NeXT spielte PHIGS oder OpenGL keine Rolle.

Die große Neuerung, die mit NeXTSTEP eingeführt wurde, war DisplayPostScript. Das ermöglichte zum ersten mal ein echtes WYSIWYG, weil der Code für die Darstellung auf dem Display und später beim Druck nahezu indentisch sein konnte. Die diversen UNIX Anbieter sogen relativ schnell nach, so daß es unter IRIX, AIX, Solaris, OSF/1 DPS gab (bei HP-UX bin ich mir nicht mehr sicher).

Der NeXT Printer hatte daher auch keinen RIP, sondern die Seiten wurden direkt auf den NeXT Workstations mit Software-RIP prozessiert.
Du kennst den Motif StyleGuide und am besten auch die Style Guides von NeXT (NeXTSTEP) und Apple (MacOS <=9.x)? IRIX hatte dann zusätzlich zum Motif Style Guide, noch einen eigenen Style Guide, der zusätzliche Anforderungen an die Programme stellte.
Schönheit ist ein extrem subjektiver Begriff, es gibt keine objektive Beurteilung was schön ist. Das hängt also immer vom Betrachter ab. Was man nun beurteilen kann, ist die Konformität eines Programmes mit den GUI Style Guides der betreffende Plattform.

Die Benutzung des Computers ist für mich die meiste Zeit kein Selbstzweck. Es ist nicht so, daß ich gutgemachte Programme nicht schätzen würde, aber gutgemachte Programme für andere FrameWorks als das System GUI FrameWork, lehne ich nicht ab. Dazu habe ich in meinem Leben schon mit zu vielen verschiedenen GUIs gearbeitet, und das häufig am gleichen Tag.
Wenn man sich mit der eigenen Herangehensweisen selbst im Weg steht, wird es halt unsinnig. Rein theoretisch kann man alles perfekt umsetzen, aber die Lebenszeit ist endlich. Dieses kleine Randbedingung sollte man nicht aus den Augen verlieren.
Nein, die Entscheidung ist einfach. Da man normalerweise Aufgaben in endlicher Zeit zu lösen hat, kann man sich nicht die Zeit nehmen, einen eigenen Editor zu coden. Das dauert einfach zu lange. Man muß sich also für einen der existierenden Editoren entscheiden. Und die häßliche Wahrheit ist nun einmal, daß die Cross Plattformlösungen am besten sind, und hier die Java Lösungen besonders glänzen. Meistens lassen sich die Java Lösungen auch in die Java IDEs integrieren, so daß es hier einen Workflow aus einem Guß gibt. Es gibt als Java Lösungen auch eine ganz Reihe weiterer Hilfsmittel zur Softwareentwicklung wie etwa RDBMS Design Tools für verschiedene RDBMSs.
Da sind wir wieder bei den finanziellen Sachzwängen. Du kannst es Dir also leisten für Monate nichts anders zu tun, als einen eigenen XML-Editor zu coden? Denn das ist keine Sache von ein paar Tagen. Da schafft man bestenfalls einen Texteditor mit Syntaxhervorhebung, aber das gibt es schon wie Sand am Meer - auf für OS X. Ergo, kann man sich eine Schmalspurlösunge gleich ganz sparen.

Stimmt. Problem ist halt, dass daraus die anderen Differenzen (abgesehen von Computer-Geschichte) folgen.
Du tust so, als ob sich Jobs' Idee des Mac ausgerechnet in AIO erschöpft hätte.

Ich rede gar nicht speziell von der DTP-Revolution, sondern von GUIs im allgemeinen, aber selbst wenn man sich auf DTP konzentriert, so verdankte sich das im Wesentlichen etlichen Eigenschaften des Macs, für die Jobs sehr wohl verantwortlich zeichnete (vielleicht berühmtestes Beispiel: Computer-Fonts).

Mag ja sein, dass DTP kommerziell erst richtig an Fahrt aufnahm, als Jobs nicht mehr bei Apple war, aber aus dieser zeitlichen Koinzidenz zu folgern, dass sein Weggang der Grund für den Erfolg Apples auf diesem Gebiet war, ist grotesk. Die entscheidenden Weichen waren allesamt vorher gestellt worden, und zwar – ich will gar nicht sagen von ihm allein, sondern von dem Mac-Team, das er leitete.
Ich muss mich da nicht groß informieren, ich war schließlich dabei. Der Magic Desktop erschien 1993, dem Jahr, als NEXT die schwarze Hardware einstellte. Mein Gedächtnis und Wikipedia stimmen da überein:

Natürlich war SGI NeXT in Sachen 3D voraus, das war schließlich deren Spezialität, und das habe ich auch nie bestritten.

Aber was hat das mit der Integration zwischen verschiedenen Programmen und Betriebssystem zu tun, um die es mir ging, weil sie nach meiner Ansicht Kreativität entscheidend fördert, und die ich bei NEXTSTEP hervorhob?
Motif und NeXT ja, Apple nein. (Apple interessiert mich persönlich erst sei seiner Reinkarnation als NeXT-Erbe.)
Stimmt. Es solte sich also jeder nach seinem richten.
Es gibt zumindest ein paar benennbare Kriterien, die Schönheit sehr im Wege stehen, und Zusammenhanglosigkeit ist sicher eines davon.

Vielleicht hätte ich aber gar nicht so sehr speziell auf Schönheit abheben sollen. Es gibt auch so was wie die intellektuelle Schönheit eines klaren Konzepts, die wenig mit Schönheit im Alltagsgebrauch des Wortes zu tun hat, und die ich mit meinte.

Sagen wir es umgekehrt: ich verabscheue gedankliches Mittelmaß, egal in welcher Hinsicht. Mit ist mein Leben einfach zu schade dazu, es mit Mittelmaß zu verbringen. Ob mir das finanziell gesehen irgendwie nützlich wäre, interessiert mich dabei praktisch überhaupt nicht, denn so sehr nützen kann es mir gar nicht, dass es den Widerwillen gegen Mittelmaß kompensiert.
Aber gemessen an meiner Prioritätenskala stehe ich mir doch eben gerade nicht selbst im Weg, sondern täte dies, würde ich so agieren wie Du.

Das alles endet in der Frage, was wir unter einem guten oder gelungenen Leben verstehen. Was muss zuvor er-lebt sein, damit wir auf unserem Sterbebett nicht bitter sind? Und das wären bei Dir eben höchstwahrscheinlich sehr andere Sachen als bei mir.

Ich gestehe Dir gerne zu, dass Deine Herangehensweise sich auf die Fahne schreiben kann, dass Du an mancherlei Messskala gemessen in Deiner Lebenszeit „mehr“ erreicht haben wirst. Aber das interessiert/motiviert mich halt nicht besonders.

Wäre ich Architekt, und eine Fee ließe mich wählen, ich könnte in meinem ganzen Leben entweder eine gigantische Stadt mit abertausenden hinreichend funktionalen Gebäuden errichten oder nur ein einzelnes, verlorenes Haus am Strand, in dem noch die letzte Mauerritze perfekt ist – ich würde sicherlich Letzteres wählen.

Ich gebe zu, dass man das aus politischer Perspektive angreifen kann und es insofern vielleicht egoistisch ist.
Natürlich kann ich das. Jeder Entwickler (na gut, sagen wir, jeder Entwickler mit soliden Kenntnissen in gefragten Bereichen) kann das – es kommt nur auf seine finanziellen Ansprüche an, da sind wir wieder beim Ausgangspunkt.

Ich verbringe in der Regel irgendwas zwischen 25% und 30% meiner Arbeitszeit mit bezahlter Arbeit, den Rest mit unbezahlten Projekten, die ich mache, weil ich sie sinnvoll finde. Davon kann ich prima leben, aber ich habe eben auch keine übermäßig großen finanziellen Ansprüche und insbesondere kein Bedürfnis nach „finanzieller Sicherheit“ (was auch immer das sein soll).

Mir ist schon klar, dass ich damit in einer sehr privilegierten Position bin und sich die Bedienung bei McDonalds das (leider) nicht erlauben könnte. Mein Punkt ist aber, dass jeder Entwickler in dieser Position ist, wenn er/sie denn will. Und deswegen lasse ich „finanzielle Sachzwänge“ als Ausrede für mittelmäßige Software nicht gelten. Wer die zu verantworten hat, soll gefälligst auch ehrlich genug sein und zugeben, dass er das so programmiert hat, weil er damit mehr Geld machen konnte und ihm das wichtiger war, als ein hervorragendes Ergebnis abzuliefern. (Ist ja OK, dass ihm das wichtiger war, solange er dazu steht und sich nicht hinter Sachzwängen versteckt.)

Was denkst Du, woher solche Phänomene wie GNU/Linux kommen?

Jobs stand sich selbst wegens seiner Art und Wiese öfters selbst im Weg. Der Erfolg des DTPs ist ganz wesentlich darauf zurückzuführen, daß es nicht nur die Techniken gab (an deren Entwicklung Jobs durchaus seinen Anteil hatte) sondern auch in der geeigneten Produktpalette. Und hier kam es erst zu Bewegungen als Jobs nicht mehr in der Firma war.
Bei was?

Wesentliche Designelemente des Indigo Magic Desktop existierten schon zu IRIS Zeiten (d.h. 4D1-3.0 bzw. IRIX 3.0 wie es später genannt wurde). Das Video zeigt IRIX 3.3.2 auf einer Personal IRIS: . IRIX 3.0 erschien nachweislich vor der ersten NeXT Demo.

Es steht außer Frage, daß Indigo Magic eine Weiterentwicklung war, aber NeXTSTEP wurde von 0.8 bis 3.3 auch verändert und blieb nicht gleich.

Wenn wir über gelungene Interaktion zwischen Programmen reden wollen, müssen wir auch über OpenDoc reden. Das sucht bis heute seinesgleichen. Sicherlich von der API nicht einfach, aber der Grundgedanke war genial. Da Apple dies zusammen mit IBM entwickelt hatte, wurde bzw. sollte es in Mac System 7.5.x, AIX und OS/2 integriert (werden). Die Implementation auf dem Mac war am besten umgesetzt. Die anderen Plattformen hingen hinterher. Bis heute gibt es nichts Vergleichbares.
Da fällt mir spontan bei NeXT die Häßlichkeit von Objective-C ein. Diese Programmiersprache vereint ganz klar die Nachteile von C und SmallTalk. Es ist weder eine Rapid Prototyping Sprache wie SmallTalk, noch ist eine effiziente OO Sprache. Die Mängel, die von C übernommen wurden, machen es extrem schwierig Rapid Prototyping zu betreiben, weil man sich ganz schnell das System mit irgend welchen Ärgerlichkeiten von C wegballert. Und auf der anderen Seite erlaubt es SmallTalk nicht effizientes OO zu machen. Es wird immer ein teures und aufwendiges dynamic Dispatching gemacht, was sehr zeitaufwendig ist.

Strenge Typisierung kennt Objective-C nicht, weil dies nicht mit den SmallTalk artigen Fähigkeiten von Objective-C vereinbar wäre und C selbst ist auch nicht wirklich streng typisiert. Diese wäre aber notwendig, um Typfehler schon zum Zeitpunkt der Übersetzung zu finden. Unit Testing ist dank des C Unterbaus wiederum auch nicht sonderlich schön umzusetzen. Dazu kommt, daß die Sprache keinerlei Elemente enthält die ganzen Unzulänglichkeiten von C in den Griff zu bekommen. Objective-C ist für mich ein fauler Kompromiß, um die ursprünglichen Probleme von SmallTalk in den Griff zu bekommen, der total verunglückt ist. Weil er die jeweiligen Schwächen der Programmiersprachen nicht löst. Lediglich das ursprünglich vorhandene Laufzeitproblem von SmallTalk wird gelöst.

Objective-C ist keine brauchbare Multiparadigmensprache, sie ist keine gute Sprache für LowLevel Aufgaben und sie ist auch keine gute OO Sprache, weil sie die C Altlasten hat und an vielen Stellen es nicht ermöglicht ohne diese auszukommen. Man muß diesen Murks in Objective-C weiternutzen.
Für mich ist Objective-C nicht nur Mittelmaß sondern noch deutlich darunter. Es ist eine einfach schlechte Programmiersprache.

gfh...

Welche Programmiersprachen kennst du denn? Und ich meine damit nicht, mal universitär etwas davongehört oder mal die IDE installiert und herum gespiel. Ich meine wirklich Projekte realisiert, die verkauft und gewartet wurden und mit denen Enduser arbeiten.

Und welche die so universell einsetzbar ist wie ObjC/C findest du denn gut?

Richtig programmiert habe ich bisher in Oberon-2, C, C++, Fortran (auch das aktuelle 2003), Postscript, PHP, JavaScript, PL/pgSQL, Tcl/Tk und Python. Die Masse an Code in C, C++, Fortran und PHP.

Zu Schulzeiten natürlich Basic, das ließ sich damals nicht vermeiden. Daneben habe ich schon Perl Skripte zwangsweise gewartet, darauf kann ich dankend verzichten.

Für eigene Zwecke mit lauffähigen Programme intensiv getestet (also nicht nur ein bisserl mit herumgespielt), um die Sprachkonstrukte auszutesten um deren Leistungsfähigkeit beurteilen zu können: Ada und Objective-C. Bei Objective-C vor allem Test mit diversen Patterns und Laufzeittest um die Dispatching Geschwindigkeit austesten zu können. Daneben habe ich noch ein privates Projekt auf der Platte herumliegen für ein Datenbankfrontend mit Cocoa. Irgend wann hat mich das so geärgert, daß ich es nicht mit vertretbaren Aufwand auf Linux portieren kann, daß ich das Projekt nicht mehr verfolgt habe. (Die Probleme treten insbesondere bei GUI-Programmen auf.) Es gibt also ein fertiges Datenbankmodell, und ein rudimentäres GUI, welches eine Beurteilung des Entwurf eines GUIs unter Cocoa zuläßt. Ich hatte dann versucht auf Python (da ich das ohnehin kenne) für Cocoa umzuschwenken, und ggf. für Linux mit Python + Irgendwas ein neues GUI zu schreiben. Aber die faktischen Probleme lassen mich zum Schluß kommen, daß das definitiv kein allzu sinnvoller Weg ist.
Ich habe hier privat eine Laufzeitumgebung für ein erweitertes C++ herumliegen, weil mich das fehlende dynamic Dispatching stört. (Das Reflection Pattern in C++ umzusetzen ist ein Graus.) Todo ist einen Compiler zu schreiben. Daran sieht man, ich bin definitiv nicht mit den vorhandenen Programmiersprachen zufrieden. C ist meiner Erfahrung nach ein absolutes NoGo für neue Projekte, wenn ich das beeinflußen kann verwende ich es nur noch zu Wartungszwecken.

C++ ist definitiv besser als C, in wirklich allen Belangen. Allerdings ist die Sprache deutlich komplizierter und es gibt mindestens den C Weg und den C++ Weg in C++ Probleme zu lösen. Personen die C schon länger kennen, neigen dazu den C Ansatz zu wählen. Das ist immer suboptimal, und führt meist schnell zu langsamen und schlecht zu wartenden Programmcode, weil irgend wo doch C++ Sprachelemente genutzt werden - etwa die STL, und sich das dann beißt. C++ erlaubt es mit C++ Sprachmittel meist mit mehr als einen Weg ein Problem zu lösen, was die Sprache sehr komplex macht. Viele Programmierer sind davon total überfordert, auch wenn sie C++ schon Jahre nutzen.

Die große Stärke sind zweifelsfrei die Templates und die recht strikte Typisierung. Mit den Templates ist es möglich static generative Programming zu machen. D.h. ansatzweise Metaprogramme zu schreiben (die Templates sind selbst eine Turing vollständige Programmiersprache), die zum Compilezeitpunkt typsichere schnellere Programme generieren. Hier fehlt meiner Meinung nach eine konsequente Weiterentwicklung. Ein Beispiel sind die vollkommen intransparenten Fehlermeldungen beim Programmieren mit Templates, der meisten Compiler, und fehlende Sprachelemente die das Schreiben von neuen Templates verbessern, wie Konzepte ein neuer Präcompiler der alle C++ Datentypen kennt, und so etwas wie Typen Variablen kennt.

Die einzige Stärke von Objective-C ist das dynamic Dispatching, das macht es sehr einfach das Reflection Pattern umzusetzen. Aber es ist auch gleichzeitig die größte Schwäche der Sprache. In der schönen theoretischen Welt der Informatik, mag dynamic Dispatching als alleiniges Dispatching in einer Programmiersprache ideal sein, weil es die Komplexität der Programmiersprache gering hält. Weil es universeller ist als static Dispatching, kann man mit diesem Sprachelemente auch mehr Probleme lösen. Nur in der Realität ist es deutlich ineffizienter. Wenn ich es also immer verwenden muß, wird mein Programm langsamer. Wenn man etwa HPC Programme schreibt, dann ist das ein riesiges Problem, was dazu führt das Objective-C als Sprache komplett für diese Art von Problemen ausfällt. Die Alternative wäre es auf reines C auszuweichen, dazu siehe oben.

Nachfolgend bin ich mir nicht sicher, ob diese Punkte noch zutreffen oder ich mich falsch daran erinnere:
Dann fehlen mir in Objective-C Sprachelemente: wie Multiple Dispatching, Metaklassen, (Klassenmethoden existieren) aber dafür keine Klassenattribute (die statics funktionieren ähnlich sind aber keine echten Klassenattrribute), Mehrfachvererbung (die Protocols sind nur eine Mehrfachvererbung von Methodendefinitionen)

Javascript hat nicht viel mit Java zu tun - außer den 4 Buchstaben im Namen, Ähnlichkeiten in der Syntax und dass beides Markennamen von SUN sind.
Ansonsten zwei verschiedene Technologien.

Java im Browser zu deaktivieren ist grundsätzlich sinnvoll.... ganz im Gegensatz zu Javascript - dann macht das Surfen nur noch bedingt Spaß.

Okay, bei so vielen Leuten, die so viel Text schreiben, den kein Normalsterblicher versteht, drängt sich mir der Verdacht auf, dass ich von Programmierern im Allgemeinen auch kein Verständnis bei Problemen im Umgang mit ihrer Software erwarten darf.
Meine Frage war zu allgemein, das habe ich begriffen. Java als "Tool" um Software auf mehreren Plattformen anzubieten, auch. Wenn sich also noch mal jemand die Mühe machen will, beschränke ich meine Frage auf das Web: wozu brauche im Java im Browser? Das Internet ist sowieso plattformunabhängig und ist es immer mehr geworden. Seiten, die unbedingt irgendwelche ActiveX Steuerelemente wollten, kenne ich nicht mehr.

Darauf kann man keine allgemeingültige Antwort geben. In Unternehmen kann es sein dass Intranet-Funktionen Java-basiert sind oder sogar ganze Anwendungen existieren die über HTTP geladen werden.
Im Privatumfeld gibt es auch einige Anwendungen oder Spiele (wie Minecraft) die das Plugin benötigen.

Aus meiner Sicht sollte es jedoch generell ausgeschaltet sein - und nur bei Bedarf explizit aktiviert werden.

Da hake ich mal ein. Warum? Warum wird das dann nicht rein über Intranet (HTML+...) erledigt oder gleich ein Programm ausgeliefert? Plattformunabhängigkeit kann es (dort wo ich darauf treffe) nicht sein, da eh nur Windows zugelassen.

Manchmal sind solche Dinge einfach historisch gewachsen. Vor 10 Jahren waren Java-Anwendungen ja weitaus häufiger anzutreffen als heute... und viele Unternehmen nutzen funktionierende Lösungen halt recht lange. Es gibt halt immer einen Bedarf an Anwendungen die direkt im Browser laufen, die über die Möglichkeiten von HTML und Javascript hinausgehen. JAVA ist ja nur eine der Möglichkeiten... zusätzlich gab und gibt es noch .NET (clientseitig per Plugin im Browser), Flash, Silverlight...

Ja und genau da hoffe ich auf Verständnis, dass mir selbiges fehlt, wenn ein Weltkonzern zwingend mit Java 6.23 arbeitet. Da wächst nichts mehr, das ist Stillstand.

Gerade größere Konzerne können doch viel langsamer reagieren... dort sind Folgen von Änderungen viel schwerer abzuschätzen, Probleme haben viel größere Auswirkungen, Änderungen in der IT sind weitaus teurer.
Vielleicht wurden Alternativen/neue Versionen durch die IT nicht zertifiziert weil sie Probleme bereitet haben... oder dies ist Folge von Budget-Kürzungen etc.
In Konzernen arbeiten ja nicht nur 2 Personen in der IT die nach Willkür entscheiden... es wird schon Gründe geben warum so etwas eingesetzt wird. Als Außenstehender lassen sich, selbst wenn man im gleichen Unternehmen arbeitet, viele Dinge in der IT nicht nachvollziehen.

Aber genau das ist doch meine Kritik an Java bzw. an dessen Verwendung. Wenn ich weiß, dass ich mit der Entwicklung meines Programms nicht so schnell bin, dann binde ich mein Programm nicht an eine Technologie, die jede Woche ein Update raushaut.

So extrem wie es aktuell ist, ist es doch erst seit etwa einem Jahr. Wirklich absehbar war das nicht. Früher waren wichtige Java-Updates weitaus seltener.
Es gab sogar eine Zeit da galt Flash als sicher... oder der Adobe Reader... oder der IE 7... und wer weiß wen oder was es als nächstes treffen wird?

Da müssen wir dann wohl einfach darin übereinstimmen, nicht übereinzustimmen. Ich habe auch mit vielen Programmiersprachen gearbeitet, aber Objective-C steht für mich einsam an der Spitze; C++ hingegen finde ich rundum schrecklich.

Um Funktionalität umzusetzen, die sich mit HTML5 alleine eben nicht umsetzen läßt. Bisher werden dazu entweder Flash oder Java Applets verwendet. Es gibt auch andere geplante Änderungen (z.B. WebGL) zu HTML, die mit großer Wahrscheinlichkeit noch schlimmer als Java sein werden, da sie auf Kernelebene im OS herumwurschteln werden. JavaScript ist mittlerweile auch immer mächtiger geworden, schlußendlich ist es egal, ob nun das Java Plugin buggy ist, oder die JavaScript Engine im Webbrowser. In beiden Fällen sind Angriffe möglich und es bedarf Updates, die die Anwender auch einspielen müssen. Und am letzten Punkt hapert es in Zusammenhang mit Java am meisten. Die Nutzer kümmern sich nicht wirklich um Updates der PlugIns.

Noch zu ergänzen, solange man Java Applets nicht braucht deaktiviert man natürlich das PlugIn.

Ich kenne Smalltalk, diese Sprache besitzt eine inhärente Eleganz die Objective-C fehlt, trotz der zum Teil etwas eigenartigen Syntax von Smalltalk. Ganz wesentlich trägt dazu bei, daß der Klotz C nicht dabei ist. Smalltalk ist kein Geschwindigkeitswunder, dafür wurde es aber auch nie entworfen. Durch Fortschritte in der VM Technik wurde das Problem auch immer kleiner. Meine Empfehlung schau Dir mal das Original an. Es gibt freie Implementierungen und mittlerweile viele Bücher frei im Netz. Vielleicht kannst Du dann nachvollziehen, weshalb ich Objective-C nichts abgewinnen kann.

C++ ist der Werkzeugkasten mit vielen Werkzeugen drin, schmutzig und häßlich aber extrem nützlich, wenn man mit den Werkzeugen gelernt hat umzugehen.

gfhfkgfhfk

Du wirfst zu viele Dinge in einen Topf und vergleichst, was nicht miteinander vergleichbar ist bzw. Technologien und Sprachen die nicht Substituierbar sind. Sprachen die eine völlig verschiedene Historie und Existenzzweck haben, lassen sich nicht gegeneinander messen. Das ist völlig praxisfremd.

Was zählt ist, zum jeweiligen Zweck auf der jeweiligen Plattform das jeweils passende und vorhandene Werkzeug (oder oftmals eine Kombination von Werkzeugen) zu kennen, zu beherrschen zu benutzen. Damit in endlicher Zeit ein sinnvolles und brauchbares Ergebnis zustande kommt. DAS macht einen guten Entwickler aus. Und nicht der ausschließlich theoretische Vergleich der Technologien. Das führt zu nichts außer Language-, Compiler- und Runtime-Benchmarking. Damit hat in der Praxis aber noch nie jemand einen Blumentopf gewinnen können. Theorie ist, wenn man alles weiss, aber nichts kann.

Es ist das Ergebnis, das zählt. Und brauchbare Ergebnisse erzielt man in C, C++, Java, ObjectiveC, C# und in allen anderen Sprachen und Umgebungen. Wenn man weiss was man tut und sie entsprechend ihres gedachten Verwendungszwecks einsetzt. Wer einer Plattform oder einer Sprache gegenüber einer anderen die Sinnhaftigkeit abspricht, hat das Prinzip nicht verstanden.

Das ist ja mein Problem. Ich darf die Updates nicht einspielen, weil dann die Software nicht mehr läuft. Solche Probleme kenne ich bei den anderen genannten nicht, zumindest nicht in dem Maße.

Dann ist die SW bzw. deren fehlenden Updates das Problem, nicht aber Java

Ich würde sagen das sowohl die Anwendersoftware als auch die Java hier beide das Problem sind. Wobei nicht Java als Sprache sondern der Javainterpreter denn der wird und muß ja dauernd "geupdatet" werden. Dafür das die Anwendungssoftware damit nicht zurecht kommt und wegen Sicherheitsupdates des Interpreters nicht mehr richtig läuft (warum sollten die Updates sonst verboten sein) sollte man natürlich wieder die Programmierer schlagen. Elso entweder sie kriegen Prügel dafür das sie nicht besser mit den Updaes zurecht kommen oder dafür das sie sich eine so Fehleranfällige Sprache ausgesucht haben

C ist eine der Programmiersprachen, mit denen man sehr leicht viele Fehler in Programme einbauen kann. Es gibt keinerlei Sprachkonstrukte mit denen sich Resourcen sauber verwalten lassen, da ist immer 100% Handarbeit gefordert, in dem man zum richtigen Zeitpunkt die passende Funktion aufruft. Das führt sehr schnell zu Fehlern im Programm. Dieser Aspekt zusammen mit der Zeigerarithmetik ist für die meisten Sicherheitslöcher in C Programmen verantwortlich. Dazu kommt ein meistens nicht vorhandenes Error-Handling in den Programmen hinzu. (Formatstrings sind auch so ein klassischer Angriffsvektor.) Anstatt die Fehlermeldungen der Routinen auszuwerten werden sie entweder ignoriert oder das Programm abgebrochen.
Gute Ergebnisse erzielt man nur dann, wenn man vorher überprüft hat, daß man auch das richtige Werkzeug für die geforderte Aufgabe gewählt hat. Was nützt einem das dynamic Dispatching von Objective-C, wenn anschließend das HPC Programm nur so vor sich hin kriecht, weil das nun einmal zu langsam ist? Richtig - gar nichts.
Wenn man schon Objective-C dafür verwenden muß, ist man in so einem Fall auf die C Funktionalität limitiert. Demnach muß man das Programm ganz anders entwerfen und kann hier in geschwindigkeitskritischen Codeanteilen keinerlei OO verwenden.

Geht es nur um Java Software lokal, oder um Java Applets im Intranet?
Im letzteren Fall müßte man wohl mit einem Proxy die Anwendung von Java Applets auf das Intranet beschränken. So würde ich es jedenfalls machen. Wenn es nur lokale Java Programme sind, da kann man für den Webbrowser parallel ja eine neue Java Version installieren.

Hast Du denn konkret eine Anforderung für die ObjectiveC zu langsam ist? Ehrlich gesagt glaube ich das nicht. Schon auf den PowerMac G4 konnte die ObjC Runtime zehntausende Selectoren pro Sekunde aufrufen. Auf den aktuellen Core i7 ist das noch einmal eine ganz andere Hausnummer. Auch Echtzeit Game Engines unter iOS (im vergleicht zum OS X Desktop mit langsamen ARMs) laufen mit Objective C locker.

Ich glaube nicht, dass Du eine Anwendung hast, die da an eine Grenze stößt.
Und wenn, dann kann man für den speziellen Fall an der Stelle eine Lösung finden. Denn auch das dynamic Dispatching kann man umgehen. Auch die großen Apps von Apple die Real Time Datenverarbeitung machen wie Logic, Aperture oder Final Cut sind Cocoa Programme. Und mir kommen die nicht zu langsam vor.

Und natürlich ist es klar, dass es, je näher Du der Hardware kommst, umso unkomfortabler und ungemütlicher wird. Das ist logisch. Komfort kostet Rechenzeit. Wenn man sich das beim jeweiligen Problem nicht leisten kann, dann muss man halt darauf verzichten. Nicht umsonst sind alle High Performance APIs reine C APIs. Wie z.B. Core Audio, Core Foundation, OpenGL oder OpenAL.

Irgendwann, wenn Du tief genug runter gehst, hört klicki-bunti auf und die harte Welt der EDV beginnt. Aber wenn Du wirklich das letzte aus der Maschine heraus holen musst, dann ist das die einzige Wahl. Dann ist auch keine Runtime mehr da, die dir die Windeln wechselt. Dann hast Du manuelles Speichermanagement, Funktionszeiger und Inline Assembler am Hals.

An ObjectiveC und Cocoa schätze ich, dass man das beste aus beiden Welten hat. Eine schöne behütete Umgebung die für 99% aller Fälle mehr als ausreichend ist und darüber hinaus die Möglichkeit, so tief und nah an die Maschine zu gehen, wie es halt der High Performance Signalprozessor oder RayTracer benötigt, der entwickelt werden soll. Aber kein Mensch behauptet das dass ein Job für Anfänger ist.

ExMacRabbitPro
+1

Hast Du jemals HPC gemacht?

Wie bereits angesprochen mache ich HPC, und dabei sind die C++ Templates sehr hilfreich, da sie hocheffzienten Code ermöglichen und trotzdem OO Fähigkeiten zum Übersetzungszeitung ermöglichen. Duck Typing ist mit Templates möglich, aber wie gesagt nur zum Zeitpunkt der Übersetzung.
Du kennst die Intel MKL? Ich brauche Programmcode, der sich möglichst auf einem ähnlichen Niveau bewegt.
Ja toll, wenn ich auf C++ Templates verzichten will, kann ich C Makros nutzen. Das ist nur noch pfui bäh. Gefrickel bis zum Abwinken und extrem fehlerbehaftet. Been there, done that

Mein Fazit: nie wieder!
Und wie ist der schnelle Programmcode umgesetzt?Es kostet in C++ Compilezeit.
Das ist eben nicht richtig. Man kann mit C++ problemlos LowLevel programmieren, solange man nicht auf Assembler angewiesen ist, kann man damit alles machen, und der Code wird trotzdem schnell. Eben weil man so Dinge wie Thread Pinning, Speicher Allokation auf NUMA Nodes, Anpassung auf Cache Lines etc. machen kann. Die Compiler generieren mittlerweile sehr schnellen Code, der nur in absoluten Ausnahmefällen mit Assembler verbessert werden muß. Die Lebenszeit von Objekten muß man immer im Auge behalten, auch beim Programmieren von Hand.

Noch zwei Gründe gegen Objective-C: Es unterstützt weder OpenMP noch MPI.

Gut, das ist ja schon interessant, welche Programmiersprache, warum, wie und wieso (nicht) Sinn macht …

Wenn ich mich recht entsinne, geht es in diesem Thread um Java. Und da hätte ich doch jetzt gerne auch von den versierteren unter Euch gewußt, ob und wie ich eine neuere JAVA-Version installieren kann als wie die für PowerPC-Macs noch 'aktuelle' J2SE 5.0 v. 1.5.0_30-b03?

Es gibt für OSX PowerPC keine neuere Java Version von Apple. Wenn es eine neuere Version sein muß, muß man sich nach einem Build des OpenJDKs für OSX PowerPC umblicken. Im Zweifelsfall ist selbst compilieren angesagt. Etwas Suche im Netz sollte die Frage beantworten: z.B. findet man das hier

Fertige JDKs gibt es für Linux von IBM.

+1

Ich ergänze um:
OBuildFactory (ehemals: openjdk-osx-build ) von Henri Gomez
OBuildFactory: Building and Packaging OpenJDK7 for OSX
OBuildFactory: Building and Packaging OpenJDK8 for OSX

Es wird wohl nötig sein, an ein oder zwei Stellen die betreffenden Build-Skripte um die PPC-Architektur zu erweitern bzw. anzupassen, da diese standardmäßig Intel-only UBs (i386/x86_64) produzieren. Also statt "-arch i386 -arch x86_64" dann halt "-arch ppc -arch i386 -arch x86_64" oder auch einfach nur "-arch ppc", wenn man ausschließlich für PPC-Architektur bauen will.

Unabhängig davon auch lesenswert und ein Lesezeichen wert folgender Essay vom selben Entwickler, Henri Gomez: Understanding Java From Command Line on OSX

Siehe von gfhfkgfhfk und mir zuvor Gesagtes.

Letztes von Apple rausgegebenes Java-Update für Leopard am 28.06.2011:
Apple: Java für Mac OS X v10.5 - Update 10 (J2SE 5.0 wird auf 1.5.0_30 und Java SE 6 für 64-Bit-fähige Intel-Macs auf 1.6.0_26 aktualisiert), siehe dazu auch die regelmäßig angepasste Versions-Tabelle von Apple unter .