Ist Java wirklich so schlecht? (siehe Thema Komplexität)

[Stephan Theisgen]

Hallo!

Ich habe für das Thema hier extra einen neuen Thread aufgemacht, da ich befürchte, wenn ich diese Nachricht in "Komplexität" poste, dies das Thema durch einen FlameWar á la Java vs C++ untergraben würde.
Die Diskussion unter "Komplexität" hat mich doch ganz schön verunsichert, denn auch wenn ich früher absoluter C++ Anhänger war (ich habe schließlich damit angefangen) so muß ich sagen, hat mir Java doch sehr gut gefallen!
Ich habe für ein Projekt auf meiner Arbeit, wo ich ein einfaches Programm mit GUI-Steuerung entwickelen sollte, einfach mal zum Spaß Java ausprobiert, und ich war begeistert.
Auch wenn ich vorher noch nie etwas in Java programmiert hatte, so habe ich doch in atemberaubender Zeit das Programm fertig bekommen. Ich habe ca. 1/5 der Zeit gebraucht, die ich in C++ gebraucht hätte. Das lag vor allem daran, dass Java für mich viel konsistenter und damit einfacher und klarer zu programmieren war. Das traf vor allem auf das GUI-Konzept und die Thread-Steuerung zu. Wenn ich daran denke das Programm wie früher in C++ mit der MFC, oder komplizierten 3th-Party-GUI-Libs programmieren zu müssen, ohne GUI-Editor, oh mein Gott.
Auch der Programmtext war viel übersichtlicher, immerhin habe ich nur in einem Editor programmieren können (keine IDE). Natürlich gab es auch einige Nachteile. Am Ende hat mich die VM ganz schön ins Schwitzen gebracht. Zwar gabs keine Speicherlecks an sich, aber ich mußte sehr große Bilddaten verarbeiten, das bringt den Speichermanager schon schnell an den Rand seiner Möglichkeiten (ich konnte die Freigabe des Speichers nicht steuern), außerdem wäre hier eine Hardware-Beschleunigung gut gewesen, die VM war doch recht langsam.

Zusammengefaßt muß ich sagen, das ich Java in den letzten Jahren sehr unterschätzt habe. Ich finde schon, dass man merkt, dass die Sprache sehr durchdacht und konsistent ist, was das Programmieren sehr vereinfacht. Wenn ich also kleine GUI-Anwendungen schreiben soll, z.B. um meinen Workflow auf der Arbeit zu verbessern, dann geht das mit Java viel schneller. Mit C++ wäre der Aufwand das Programm zu schreiben meistens genauso groß, wie die Arbeitsersparnis, welche mir das Programm bringt. In diesem Fall würde ich Java inzwischen immer vorziehen.
Trotzdem gibs auch hier negative Seiten, ich muß auf jedem Computer die VM installieren (sehr mühsam, da ich nicht immer die Zugriffsrechte habe, die Installation nicht so easy läuft, wie man denkt und die Besitzer gegen zusätzliche Software immer Vorbehalte haben).
Bei Software die große Datenmengen verwaltet und schwierige Rechnungen ausführt (FFT auf 100-250 MB Daten) ist Java leider aufgrund der VM (Geschwindigkeit) und dem Garbage-Controller (nicht kontrollierbar) leider nicht so gut geeignet, da ist C++ viel besser.

Gibt es eigentlich einen Compiler, der aus JAVA-Code einfach ein ganz normales Programm ohne VM erzeugt? Und warum kann man den Garbage-Controller nicht zwingen was freizugeben, das würde viele Probleme, die ich mit Java habe schon lösen.

Viele Grüße
Stephan

[Hanno]

Ich kann gerade mangels Zeit nicht auf alles eingehen, aber hier zwei Punkte:

Gibt es eigentlich einen Compiler, der aus JAVA-Code einfach ein ganz normales Programm ohne VM erzeugt?

Ja, ich kenne zwei: gcj und Excelsior JET.
Zur Qualität der beiden kann ich nichts sagen.

Und warum kann man den Garbage-Controller nicht zwingen was freizugeben, das würde viele Probleme, die ich mit Java habe schon lösen.

System.gc()


Ich finde Java hat schon große Vorteile gegenüber C++, ist aber in vielen Dingen auch ein Rückschritt. Ich finde Scala ziemlich gut. Das kann alles was Java auch kann (läuft auch auf der JVM) und hat darüber hinaus viele weitere Features.

Wie gesagt, ich hab leider keine Zeit mehr zu schreiben und auf einige Punkte genauer einzugehen.

[Chromanoid]

Also ich würde sagen Java ist gerade im Business-Bereich eher best practice als irgendwas anderes...

ich kann übrigens nur matisse den gui editor von netbeans empfehlen... Das teil generiert aus der erstellten gui oberfläche sehr gut strukturierten und gut lesbaren "Gui-Generierungs-Code" wie man ihn sonst selbst schreiben würde....

bei memory management hatte ich bisher nur einmal probleme und das war wegen einem bug in einer selbstgeschriebenen gui komponente. zu memory management gibt es glaube ich recht viele artikel im internet...

java mag für spiele entwicklung nicht etabliert sein, aber bei anwendungsentwicklung ist java wirklich stark. gerade der dynamische umgang mit klassen usw. kann einem sehr viel bringen. in jasperreports bspw. wird in den report templates direkt java programmiert und die dinger werden dann einfach kompiliert und als eine art klassen in den speicher geladen... sowas könnte ich mir auch gut für level o.Ä. in einem spiel vorstellen....

@jre-installation: eigentlich muss man kein JRE auf den zielsystemen installieren, es reicht doch einfach einen jre im programmpfad mitzuliefern...

wegen bildverarbeitung und hardware-beschleunigung kann ich http://www.jhlabs.com/ip/managed_images.html empfehlen...

langsam komme ich mir hier vor wie ein technology evangelist... :D

[Krishty]

Oh, der Thread geht dann wohl auf meine Kappe als bekennender Java-Hasser und Schreihals des Komplexitäts-Threads ;)
Ich könnte da ganze Bücher drüber schreiben, aber ich versuche wirklich, es kurz zu halten. Im Voraus Entschuldigung für soviel Text.

Ich finde schon, dass man merkt, dass die Sprache sehr durchdacht und konsistent ist, was das Programmieren sehr vereinfacht.

Einfacher als C++ ist Java ohne Frage … vor allem muss man weniger lernen, bis man einfache bis mittlere Programme ordentlich schreiben kann. C++ ist eine nie enden wollende Erleuchtung, dass es doch irgendwie noch klarer, noch kürzer, noch schneller oder noch sicherer geht – leider, weil es anfangs weder klar noch kurz noch schnell und erst recht nicht sicher ist.

Aber unter Konsistenz verstehe ich was anderes als Java … jede Sprache hat irgendwo ihre Inkonsistenzen, auch mein heiß geliebtes C++ treibt mich manchmal auf die Palme. Der Unterschied ist, dass diese Macken in C++ sehr lokal sind, während sie sich in Java durch die ganze Sprache ziehen. Erklär mal einem Java-Anfänger, warum er in einer Funktion Objekt-Parameter nachhaltig verändern kann, int-Parameter aber nicht … zu verstehen, was der Unterschied zwischen Pass-by-Reference und Pass-by-Value ist, dass in Java alle Objekte (bis auf native Datentypen) Referenzen sind (und was die Ursache dieser Entscheidung ist) erfordert soviel Fachwissen, dass derjenige auch einfach direkt C++ lernen und dort von Hand festlegen könnte, wann er eine Referenz und wann eine Kopie haben möchte.
Damit, dass sie das Überladen von Operatoren rausgeschmissen haben weil es pöse ist, aber dann ausschließlich für Strings wieder aufgenommen haben weil es ohne eben auch nicht so schön ist, will ich garnicht anfangen …

das bringt den Speichermanager schon schnell an den Rand seiner Möglichkeiten (ich konnte die Freigabe des Speichers nicht steuern)

Interessant … kannst du genauer sagen, was da schief gelaufen ist? Nach dem, was mir über den Garbage-Collector der VM beigebracht wurde, sollte die fehlende Freigabe nicht das große Problem darstellen … und selbst Fragmentierung sollte brauchbar unterdrückt werden.

Zurück zum Sprachthema: Es ist mit keiner Sprache unmöglich, gute Programme zu schreiben, sowas hängt immer am Programmierer. (Ich habe Delphi für eine pure Schulsprache gehalten, bis ich gesehen habe, was Zudomon damit alles zaubert …)

Um C++ wirklich zu beherrschen braucht es Jahre, manche sagen, Jahrzehnte. Wenn ich sehe, dass ich als nicht unbegabter Programmierer nach sechs Jahren C++ immernoch ständig dazulerne (zwar nicht mehr auf täglicher, aber immerhin auf wöchentlicher Basis), stimme ich da vollkommen zu. Allerdings erlaubt C++ dafür auch jede Art von Programmierung, von Low-Level-fast-Assembler bis zu anders schwer erreichbarer Metaprogrammierung, während man gleichzeitig jede Facette des Programms mit voller Kontrolle feintunen kann. Aber aus großer Macht folgt eben auch große Verantwortung ;)

Also ich würde sagen Java ist gerade im Business-Bereich eher best practice als irgendwas anderes...

(Leider?) Richtig … Java/C# ist viel schneller auszubilden (egal ob an der Uni oder im Juuuob). Und wenn man jemanden mit einem halben Jahr Programmiererfahrung an einem Produkt arbeiten lässt, wäre es ja auch unverantwortlich, es nicht in einer VM laufen zu lassen ;)
Dass allerdings von den leistungsfähigsten und ausgefeiltesten Programmen jemals mehr als eine Handvoll in Java geschrieben wird, wage ich zu bezweifeln, eben weil man – wie im Komplexitäts-Thread beschrieben – (nicht nur durch die VM und Garbage-Collection) schwer alle Auswirkungen eines Codeabschnitts kontrollieren, ja meist nicht einmal überblicken kann. (Der Fairness halber: auch auf C/C++ wird bei missionskritischen Programmen oft verzichtet.)

Sooo, nun habe ich ewig lang meinen Standpunkt beschriebenskizziert, und was bringt es Stephan? Eine FFT auf hunderte MiB wird in keiner Programmiersprache schnell sein. Wenn du an die Grenzen der Sprache stößt ist das zwar ärgerlich, aber bevor du auf eine andere Sprache umsteigst, sei dir im Klaren: Die zu lernen wird Jahre dauern, egal, ob es nun C++ ist oder was anderes. Das lohnt sich in den seltensten Fällen … Hannos & Chromanoids Tipps sind da sicher effizienter.

Wenn ich im Komplexitäts-Thread dauernd auf C++ ausgewichen bin, hatte das folgenden Grund: Ich weiß eben am besten in C++, wie sich das Problem lösen ließe und Java ist C++ in der Syntax nicht unähnlich (die Chance, dass sich die Lösung auf Java hätte übertragen lassen, also hoch). Ich hätte garnicht erst nachsehen sollen, wie das mit Java aussieht, dann hätte mich das nicht aufgeregt und es hätte nicht so ausgesehen, als wenn ich da jemandem C++ aufbinden wollte ;)

Gruß, Ky

[Schrompf]

Hier würde ich wieder meckern, dass wieder die Sprache (C++ vs. Java) und das Framework (MFC gegen JavaWasWeißIch) vermischt werden. Auf Seiten der Sprache ist mir Java schlicht zu simpel, zu beschränkt. Operatoren, Templates, Closures, usw... das fehlt mir. Auf der Framework-Seite ist Java phantastisch ausgestattet - die schon genannten Hilfen für GUI-Design oder für's Threading sind unglaublich hilfreich. Auf C++-Seite muss man sich da erst ein schönes Framework suchen und einrichten, was definitiv nicht einfach ist.

Meine Meinung also: Die Programmiersprache Java ist schlechter als C++, das Framework besser. Und damit wäre die Antwort auf die Frage im Threadtitel konsequenterweise: Ja, Java ist wirklich so schlecht.

Ich muss mir irgendwann mal Scala angucken.

[Aramis]

Ehrlich gesagt fallen mir außer 'Primitiven-sind-kein-Objekte' und diesem, darauf aufbauenden, entsetzlichen Auto-boxing keine Inkonsistenzen in Java ein, schon gar nicht solche, die sich durch die ganze Sprache ziehen. Der '+'-Operator für java.lang.String ist kein wirklicher Fall von operator-overloading, denn man kann `+`ja nicht wirklich für eigene Klassen überladen. Es ist einfach eine von der Sprache vorgesehene, kontextabhängige, zweite Bedeutung des '+'-Operators. Mit Operator-Overloading im C++-Sinne hat das nichts zu tun. Man hätte auch einen neuen Operator einführen können .. zum Beispiel '.', wie in PHP. Aber hätte es das intuitiver gemacht?

Und vor allen, könnte man nicht eine endlooos lange Liste von C++-Ungereimtheiten aufstellen? Hast du ja auch selber gesagt, nur dass du diese Ungereimtheiten, Sonderfälle und Überaschungen der Sprache als 'Erleuchtungen' bezeichnest. Der Tellerrand lässt grüßen :-)

Unterschied zwischen Pass-by-Reference und Pass-by-Value ist, dass in Java alle Objekte (bis auf native Datentypen) Referenzen sind (und was die Ursache dieser Entscheidung ist) erfordert soviel Fachwissen

Braucht es wirklich sooo viel Fachwissen? Das Konzept einer Referenz ist leicht erklärt, und nach kurzer Zeit intuitiv. Die Feinheiten, z.B. dass Java ja strenggenommen _alles_ pass-by-value übergibt, muss man nicht zwingend kennen um Java sauber nutzen zu können. Selbst wenn, nach kurzer Zeit kommt man von selber drauf. Vielleicht ist diese Frage aber auch nur für diejenigen interessant (bzw. wichtig zu wissen), die aus der C/C++/...-Ecke kommen. Denn nirgendwo sonst ist die pass-by-whatever Frage so wichtig.

dass derjenige auch einfach direkt C++ lernen und dort von Hand festlegen könnte, wann er eine Referenz und wann eine Kopie haben möchte

Vielleicht vergisst derjenige dann das Referenzzeichen doch mal, und sucht später 10 Stunden nach dem Fehler. Thema Produktivität. Und die ist bei Java aufgrund geringerer Fehleranfälligkeit und der gigantischen class library eben eindeutig höher (ähnlich wie bei C#). Das richtige Tool für den richtigen Zweck. C++ vorzuziehen weil du etwas mehr Kontrolle über einen Codeabschnitt hast, geht am Ziel vorbei.

PS: Ich mag Java auch nicht. vielleicht, weil meine ersten Programmiererfahrungen in Java stattfanden. Vielleicht auch, weil ich im Übermut kurz darauf 80Kloc+1000Tassen Java auf ein überdimensioniertes, unterstrukturiertes und schlussendlich gescheitertes Spieleprojekt verschwendet hab. Trotzdem will und kann ich Java einfach nicht verteufeln.

[Alexander Kornrumpf]

Fürs Protokoll: Die Dinge die hier genannt wurden:
-Primitive verhalten sich anders als Objekte (vs. C++'s "behave like int")
-String verhält sich nochmal anders
sind mir an Java auch vom ersten Tag an auf den Zeiger (Kalauer, hehe) gegangen. Ich sehe das aber als Geschmackssache.

[Stephan Theisgen]

Je, so schnell wie hier geschrieben wird kann ich nicht antworten. Sorry wenn ich also seltener dazu beitrage.
Eines vorweg, ich programmiere meine Engine und meine Spiele immer noch in C++. Ich kenn mich da einfach besser aus und ich habe mehr Kontrolle, was in diesem Bereich auch sehr wichtig ist. Ich mache das hobbymäßig, und habe auch die Zeit die ich aufwenden muß, um die größere Komplexität, durch mehr Kontrolle zu beherrschen.


@Hanno: gcj und Excelsior JET kannte ich noch nicht, vielen Dank für den Tip, wie gesagt, ich beschäftige mich noch nicht so lange mit Java. System.gc() funktioniert leider nicht so wie gedacht. Ich hatte den Eindruck er räumt eher auf was er will, und nicht was ich will.

@Krishty: Ich dachte bisher über Delphi ähnlich. Trotzdem liegt mir der Syntax nicht so, aber das ist Geschmacks- und manchmal auch Gewöhnungssache (auch wenn ich aus der Ecke komme.) Mein Problem mit dem Garbage-Collector der VM war eher ein anderes. Ich hätte gerne mehr Speicher freigegeben, da ich gemerkt habe das mein Arbeitsrechner sehr langsam wurde, der Garbage-Collector schien aber der Meinung zu sein, dass das noch nicht nötig ist (Ich habe lange danach gesucht, ob das Objekt auch wirklich frei gegeben wurde, oder irgendwo noch versteckt referenziert wurde, habe aber nichts finden können.) Insofern war das eher ein Problem mit dem Zusammenspiel Java / Windows... Aber das macht es ja nicht besser.

"Oh, der Thread geht dann wohl auf meine Kappe als bekennender Java-Hasser und Schreihals des Komplexitäts-Threads "

Das ist jetzt doch etwas hart, so kam mir der Thread gar nicht vor.

@Schrompf: Ich weiß das ich Framework und Sprache gemischt habe. Aber gerade in dem hier beschriebenen Fall, dass das Programm möglichst schnell und effektiv erstellt werden soll, durch mich alleine, etc...; sich also ein kompliziertes Setup und Einarbeiten nicht lohnt, dann hat die Verfügbarkeit eines guten built-in-Frameworks durch aus einen entscheidenden Einfluß auf die Sprache. Auch wenn ich natürlich das Framework von Java mir einfach in C++ nochmal neu schreiben könnte, aber was für ein Aufwand.

@alle: Im übrigen muß ich mal ein Lob aussprechen, der Thread ist noch kein FlameWar geworden und ich habe richtig viel dabei über mögliche Schwächen und Stärken der Programmiersprachen gelernt.

Grüße
Stephan

P.S.: Wenn meine Aufgabe darin besteht ein optimales Programm / Framework / Engine etc. zu erstellen und ich ein Team gut ausgebildeter Programmierer zur Verfügung habe, würde ich wohl C++ vorziehen, weil ich eben die beste Kontrolle habe und die größere Komplexität, etc.
Aber wenn ich ein Programm schreibe (selbst mal eben), das mir die Arbeit erleichtern soll, vielleicht der Code garnicht wiederverwendbar sein muß oder der Code nur für mich und nicht für andere nützlich ist (ich also deutlich begrenztere Resourcen zur Verfügung habe und es sich nur lohnt, wenn ich möglichst effektiv das Programm erstellen kann), dann würde ich Java bevorzugen.

[Stephan Theisgen]

Ok, dieses by-ref und by-val finde ich jetzt nicht SO schlimm bei Java. Wenn man das Konzept (in C++) verstanden hat, versteht man es auch ohne Probleme in Java.
Allerdings muß ich sagen, dass dies, wenn man wie ich aus der C++-Ecke kommt schon ein wenig Kopfschmerzen machen kann. Denn man versteht das Konzept zwar gleich, es aber auch zu verinnerlichen und anzuwenden, ich meine so aus dem Reflex heraus, ist als eingefleischter C++-Programmierer schon schwerer, so finde ich.

Blöder fand ich allerdings auch, dass native Datentypen keine Objekte sind (Auto-boxing ist grausam). Warum überhaupt so kompliziert. Der Compiler sollte doch in der Lage sein zu erkennen, wann es nicht nötig ist ein Int-Objekt extra so anzulegen und er es auf ein natives int optimieren kann?

Ein einfaches delete(Object) oder free(Object), um die Kontrolle über den GC zu bekommen würde doch schon reichen. Vielleicht liefert dann auch free = false, wenn das Objekt nicht gelöscht werden konnte, weil noch Referenzen existieren. Das fände ich gut. Dann kann man arbeiten wie bisher, muß beim Kleinkram sich nicht um Speicherlecks etc. kümmern und kann bei wichtigen Teilen selber kontrollieren, wann und wo man freigeben möchte, falls möglich, falls nicht, weiß man, dass was im Programm falsch läuft.

[Aramis]

Um Alex Kornrumpf ganz frech aus dem Komplexitätsthread zu zitieren:

Prinzipiell finde ich den Verzicht auf echte Mehrfachvererbung zugunsten von Interfaces übrigens richtig.

Sehe ich genauso. Mehrfachvererbung und das Diamond-Problem sind ein schönes Beispiel für eine alles andere als lokal begrenzte Inkonsistenz in C++. Virtuelle Basisklassen sind so ziemlich der übelste, offizielle 'Hack' der mir grade einfällt.

Aber aus großer Macht folgt eben auch große Verantwortung

Trägt man diese Verantwortung dann nicht am besten wenn man, aus dem Wissen selber auch nicht fehlerfrei zu sein, Teile dieser Macht delegiert?
Zum Beispiel an einen Interpreter mit GC :-)

PS: Ich schlage vor die Threads zusammenzuführen.

[Krishty]

Huch, der Thread explodiert óÔ

Ehrlich gesagt fallen mir außer 'Primitiven-sind-kein-Objekte' und diesem, darauf aufbauenden, entsetzlichen Auto-boxing keine Inkonsistenzen in Java ein, schon gar nicht solche, die sich durch die ganze Sprache ziehen.

Ziehen die sich etwa nicht durch so ziemlich jede Zeile? Und sind zwei nicht schon zwei zuviel?

Hier wollte ich noch was zum Operator + schreiben, aber Alexander Kornrumpf und Stephan Theisgen haben das mit den Strings, nativen Typen und Objekten ja auch schon wiederholt, also wumpe.

Und vor allen, könnte man nicht eine endlooos lange Liste von C++-Ungereimtheiten aufstellen? Hast du ja auch selber gesagt, nur dass du diese Ungereimtheiten, Sonderfälle und Überaschungen der Sprache als 'Erleuchtungen' bezeichnest.

Würde ich nie tun … im Gegenteil, so wundervolle Lösungen wie sie durch Templates möglich sind sind keine Ungereimtheiten, sondern wären bei der kleinsten Ungereimtheit unmöglich (darum hatten wir ja bis in die 00er das Problem, dass Template-Code kaum unter den Compilern portabel war).

Die Feinheiten, z.B. dass Java ja strenggenommen _alles_ pass-by-value übergibt, muss man nicht zwingend kennen um Java sauber nutzen zu können. Selbst wenn, nach kurzer Zeit kommt man von selber drauf. […C++…] Vielleicht vergisst derjenige dann das Referenzzeichen doch mal, und sucht später 10 Stunden nach dem Fehler.

Das war ja gerade das Thema des Komplexitäts-Threads – wenn nicht alles über strenge Interfaces läuft, kann ich irgendwann nicht mehr sagen, wann eine Funktion was verändert und wann nicht, und wann ich überhaupt welches Objekt in der Hand habe. Und das ist dann weniger schlimm, als wenn ich ab und zu mal ein Zeichen vergessen könnte?

Sehe ich genauso. Mehrfachvererbung und das Diamond-Problem sind ein schönes Beispiel für eine alles andere als lokal begrenzte Inkonsistenz in C++. Virtuelle Basisklassen sind so ziemlich der übelste, offizielle 'Hack' der mir grade einfällt.

100 % Zustimmung

Trägt man diese Verantwortung dann nicht am besten wenn man, aus dem Wissen selber auch nicht fehlerfrei zu sein, Teile dieser Macht delegiert?
Zum Beispiel an einen Interpreter mit GC :-)

GC gibt es doch in C++ genauso, man muss eben nur ein paar Tage investieren, sich in die ganzen Hilfsklassen aus ::std, ::boost etc einzuarbeiten. Es ist in C++ möglich, genauso abstrakt wie in Java zu arbeiten (streng genommen sogar abstrakter), wenn man nur will – bis man soweit ist, muss man aber ordentlich leiden und einer ständigen Versuchung widerstehen. Außerdem, wenn sich niemand der Verantwortung stellt, bringt auch niemand die Superschurken zur Strecke.

Thema Produktivität. Und die ist bei Java aufgrund geringerer Fehleranfälligkeit und der gigantischen class library eben eindeutig höher (ähnlich wie bei C#).

Habe ich ja auch schon gesagt, aber da tendiere ich jetzt ganz stark zu Schrompfs Meinung. Mit der Sprache selber hat das wenig zu tun.

… sind mir an Java auch vom ersten Tag an auf den Zeiger (Kalauer, hehe) gegangen.

I lol'd :D

Eines vorweg, ich programmiere meine Engine und meine Spiele immer noch in C++.

Achso, wusste ich nicht. Dann ist deine Meinung zu dem Thema erfahrener als meine, da ich nur sporadisch mit Java und hauptsächlich mit C++ arbeite.

[Stephan Theisgen]

@Krishty:

Achso, wusste ich nicht. Dann ist deine Meinung zu dem Thema erfahrener als meine, da ich nur sporadisch mit Java und hauptsächlich mit C++ arbeite.

Naja das glaube ich nicht unbedingt. Ich programmiere seit ca. 12 Jahren C++ und seit ca. 1 Jahr Java (hat mit einem Uni-Kurs angefangen und dann habe ich es für ein paar kleine Projekte zur Arbeitserleichterung benutzt, sowas hatte ich schon früher gemacht, aber bis dahin in C++.) Ich arbeite allerdings in der Wissenschaft und nicht im Bereich Computer...
Die Länge der Zeit die man Programmiert sagt nicht unbedingt etwas über das Können aus.

Offtopic: Übrigens habe ich letzte Woche gerade Deinen Artikel über das Rendern von Sternen durchgearbeitet. Super Artikel! Vielen Dank! Es hat zwar einige Zeit gedauert, da man nicht einfach copy&paste machen kann! Und das ist auch gut so!!! Hat aber super funktioniert!

[Chromanoid]

Wenn meine Aufgabe darin besteht ein optimales Programm / Framework / Engine etc. zu erstellen und ich ein Team gut ausgebildeter Programmierer zur Verfügung habe, würde ich wohl C++ vorziehen, weil ich eben die beste Kontrolle habe und die größere Komplexität, etc.

Aus risikopolitischer Sicht wäre das aber evt. eine Fehlentscheidung, da du nicht weißt wie lange dir dieses Team zur Verfügung steht und ob es sich wirklich um gut ausgebildete Programmierer handelt. Läuft es dann nicht meistens eh darauf hinaus, dass man für die "einfacheren" Sachen eine Scriptsprache einbindet?

Aber wenn ich ein Programm schreibe (selbst mal eben), das mir die Arbeit erleichtern soll, vielleicht der Code garnicht wiederverwendbar sein muß oder der Code nur für mich und nicht für andere nützlich ist (ich also deutlich begrenztere Resourcen zur Verfügung habe und es sich nur lohnt, wenn ich möglichst effektiv das Programm erstellen kann), dann würde ich Java bevorzugen.

Diesen absoluten Irrglaube, dass java Code schlecht wiederverwendbar sei, schlecht von anderen lesbar ist und für "echte" Applikationen nicht geeignet ist, solltet ihr euch wirklich aus dem Kopf schlagen :).
Java ist dank Java plattform die mit am besten wiederverwendbare Sprache die es im Moment gibt. Projekte, die mit Java entwickelt worden sind, sind dank Paket-Struktur, dynamischer Bindung und JavaDoc etc. wesentlich leichter zu erweitern, zu verstehen und zu warten. Ich kann ja noch verstehen, wenn man C#+.Net für besser und flexibler hält, aber C++ ist ein Artefakt des vorherigen Jahrtausends, das nur noch für hardware kritische aufgaben taugt ;).. :twisted:

[Alexander Kornrumpf]

Java ist dank Java plattform die mit am besten wiederverwendbare Sprache die es im Moment gibt. Projekte, die mit Java entwickelt worden sind, sind dank Paket-Struktur, dynamischer Bindung und JavaDoc etc. wesentlich leichter zu erweitern, zu verstehen und zu warten. Ich kann ja noch verstehen, wenn man C#+.Net für besser und flexibler hält, aber C++ ist ein Artefakt des vorherigen Jahrtausends, das nur noch für hardware kritische aufgaben taugt

Ich sehe nicht wo die Dinge die du genannt hast Java-Spezifisch sind.

Pakete/Dateien: Ich hab (durch langes nicht benutzen von Java) vergessen was Pakete können was Namespaces nicht können. Ich finde es jedoch eher nervig dass in jeder Datei nur eine Klasse sein darf die genau so heißt wie die Datei und dass Pakete umgedrehte URLs als Namenskonvention haben. Auch die Trennung von Definition und Deklaration (und die dadurch recht übersichtlichen Header) spricht eher für C++. C# hat z.B. noch partial classes, in erster Linie wohl um Designer Code zu verstecken. Wie ist das bei Java?

JavaDoc: Ähm Doxygen? ... phpDoc *g*

Es mag sein das Unternehmen mittlerweile begriffen haben wie Wiederverwendung funktioniert, kann ich nicht beurteilen. Im akademischen Umfeld und bei OpenSource sehe ich diesbezüglich noch keinen großen Fortschritt. Wenn ich mit Linux arbeite sehe ich an Paketabhängigkeiten dass da wohl was wiederverwendet wurde. Das ist dann aber meist kein Java Code. Je weiter sich OSS vom System entfernt desto mehr tendiert jeder dazu sein eigenes Süppchen zu kochen. Die Fälle von Wiederverwendung die ich mit Java erlebt habe waren eher von der Art, dass Komponenten die wiederverwendet wurden entweder nur vom Autor verstanden wurden, an entscheidenen Stellen so langsam waren dass sie unbrauchbar wurden, oder das eine Feature was man unbedingt brauchte nicht in das Konzept der Komponente passte.

Ich sage nicht diese Probleme wären Java spezifisch. Zu behaupten das Java (und das damit verbundene Over-Engineering) sie gelöst hätten ist jedoch mehr als übertrieben (was ich eher schade finde).

[Chromanoid]

JavaDoc: Ähm Doxygen? ... phpDoc *g*

Bei Java gehört das dazu und wird sozusagen nativ unterstützt. Genauso wie Exceptions, Logging, usw.

Ich finde es jedoch eher nervig dass in jeder Datei nur eine Klasse sein darf die genau so heißt wie die Datei und dass Pakete umgedrehte URLs als Namenskonvention haben.

Ersteres dient, wenn extrem der übersicht. Letzteres hilft, dass man nicht ständig mit anderen Entwicklern ins Gehege kommt, da man in Java immer sehr viel wiederverwendet ;).

Ich sehe nicht wo die Dinge die du genannt hast Java-Spezifisch sind.

Bei Java und anderen dynamischen Sprachen ist jede Klasse und jedes Paket flexibel ersetzbar und funktionieren praktisch nativ als DLLs.

Ich persönlich bin natürlich auch nicht frei von Gutfinden durch Gewöhnung :). Ich habe noch nie professionell C++ programmiert. Einigermaßen professionelle Erfahrung habe ich nur in Java, ActionScript3 und VBA... Wobei da Java und ActionScript (ActionScript nochmal wesentlich weniger Stunden als Java) stundenmäßig sicherlich weit vorne liegen. Java programmieren tue ich ungefähr seit 6 Jahren. In C++ habe mehrere Hobbyprojekte angefangen. Darunter zwei 2D-Engines (DirectDraw) und zwei 3d Engines (OpenGL). Alle Projekte waren recht weit fortgeschritten und ich habe ca. 2 Jahre lang regelmäßig für die Projekte programmiert.
Seit dem ich Java und andere Sprachen wie C# und ActionScript kenne, macht mir programmieren wieder Spaß. Das mag zum einen daran liegen, dass ich in C++ nur hobbymäßig entwickelt hab und vielleicht nie einen vernünftigen Programmierstil gefunden hab und zum anderen weil ich durch pointer, memory management etc. in C++ immer soviel Zeit geopfert habe, dass ich die Sprache nicht mehr sehen konnte. Für das iPhone programmiere ich im Moment auch ein bisschen C++ und da ist mir prompt wieder ein kleiner aber feiner Fehler passiert, der mir langes suchen in meinem Quelltext beschert hab. Das ganze war dann ein typischer (C++ Anfänger) Fehler, der mir schnell vor Augen geführt hat was ich an Sprachen wie Java so mag:

Code: Alles auswählen

//In der Header-Datei:
GLushort *indices;
//im constructor in der Header-Datei:
indices=new GLushort[numIndices];
//in der Funktion loadVBO in der cpp datei:
glGenBuffers(1, &vboIndicesName);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, vboIndicesName);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, numIndices*sizeof(GLuint), &indices[0], GL_STATIC_DRAW);

Ich hab echt lange gebraucht um den Fehler zu finden... Obwohl es sich einfach nur um einen kleinen Tipp/Erinnerungsfehler gehandelt hat. Sowas passiert einem in Java nicht so schnell... Vielleicht benutze ich da in C++ auch die falschen Mittel. Vielleicht könnt ihr mir ja sagen, wie man solche Fehler in C++ von vorneherein verhindert... Ich meine sowas passiert doch in C++ ständig. (in diesem beispiel wäre es wohl einfach sinnvoller gewesen "numIndices*sizeof(indices[0])" zu machen, aber gerade am anfang passiert einem sowas ständig. da kann man sich beim lernen von java gleich um die wesentlichen dinge kümmern... Denn dort gehört das umfangreiche Framework mit zur Sprache und verschmilzt sozusagen mit der Java-Sprache. In C++ empfinde ich das nicht so...)

[Krishty]

Bei Java gehört das dazu und wird sozusagen nativ unterstützt. Genauso wie Exceptions, Logging, usw.

:shock: Falls du dich damit auf die Bibliotheken beziehst: Die C++-Standardbibliothek arbeitet genauso mit Exceptions und standardisierten Logging-Verfahren.

In C++ empfinde ich das nicht so...

Ja, das stimmt allerdings. Um sich auf das Beispiel zu beziehen: vor allem Schnittstellen wie OpenGL und DirectX sind meilenweit von sicherem Stil entfernt  … und wenn man gegen Funktionen coded, die ihre Parameter noch auf C-Level entgegennehmen, bringen einem die höheren Sprachfeatures auch nichts mehr.

Das ist aber wieder Framework, nicht die Sprache selbst. Der Beispielcode ist gegen ein C-Interface geschrieben und wenn du selbiges in Java füttern müsstest, würde das mangels Zeigern noch weniger funktionieren ;) Ein Lichtblick ist allerdings in Sicht: Direct2D arbeitet – so habe ich gehört – mit Namespaces, Referenzen, const-Correctness, RAII und Templates … also „echtem“ C++. Ich hoffe, dass MS es endlich kapiert hat.

Btw: Wie sieht es generell mit DirectX-Support unter Java aus?

@Stephan Theisgen & Offtopic: Danke, höre ich gern :)

[Chromanoid]

Btw: Wie sieht es generell mit DirectX-Support unter Java aus?

In java kann man dank bibliotheken wie JNA ohne Probleme jede DLL einbinden. Es ist die Frage ob das jemand mit DirectX schon getan hat.

Das ist aber wieder Framework, nicht die Sprache selbst. Der Beispielcode ist gegen ein C-Interface geschrieben und wenn du selbiges in Java füttern müsstest, würde das mangels Zeigern noch weniger funktionieren Ein Lichtblick ist allerdings in Sicht: Direct2D arbeitet – so habe ich gehört – mit Namespaces, Referenzen, const-Correctness, RAII und Templates … also „echtem“ C++. Ich hoffe, dass MS es endlich kapiert hat.

Naja in einer guten Java OGL Implementation ist sowas ja dann eh gekapselt. In Java bekommt man von sowas einfach nichts mit...

[Krishty]

In java kann man dank bibliotheken wie JNA ohne Probleme jede DLL einbinden. Es ist die Frage ob das jemand mit DirectX schon getan hat.

Okay, klingt gut. Kam mir eben in den Sinn, weil ich in Verbindung mit Java bisher nie D3D gesehen habe.

Naja in einer guten Java OGL Implementation ist sowas ja dann eh gekapselt. In Java bekommt man von sowas einfach nichts mit...

Ja, für C++ müsste es theoretisch auch gewrappt, gekapselt und schick verpackt werden. Praktisch tut das aber scheinbar kaum jemand, weil es mit der C-Abwärtskompatibilität ja schon irgendwie geht … da kommt dann auch der schlechte Ruf her.

[Chromanoid]

Pakete/Dateien: Ich hab (durch langes nicht benutzen von Java) vergessen was Pakete können was Namespaces nicht können. Ich finde es jedoch eher nervig dass in jeder Datei nur eine Klasse sein darf die genau so heißt wie die Datei und dass Pakete umgedrehte URLs als Namenskonvention haben. Auch die Trennung von Definition und Deklaration (und die dadurch recht übersichtlichen Header) spricht eher für C++. C# hat z.B. noch partial classes, in erster Linie wohl um Designer Code zu verstecken. Wie ist das bei Java?

Wie du schon sagst: Alle klassen ordnet man in eine Ordner-Struktur an. Per Namenskonvention sind die ersten Ordner i.d.r. Domains der Entwickler, dann folgt der Projektname:
z.B. info.zfx.zfxce
siehe auch http://en.wikipedia.org/wiki/Java_package
Das ganze hat im grunde den gleichen Effekt wie namespaces. Nur dass jeder Entwickler die auch tatsächlich benutzt, weil es in java einfach dazu gehört. Man geht so Namenskollisionen aus dem weg. gerade durch den Domainnamen kann man sich nicht ins gehege kommen. In Java haben packages auch "physikalische" auswirkungen, da sie auch eine ordnerstruktur vorgeben. Das sorgt für zusätzlichen (erzwungenen) Überblick und Kollisionsfreiheit. Mit protected versehene Methoden und Variablen sind nur von Kindklassen und Klassen im selben Paket aufrufbar. Partial classes gibt es in Java nicht.

Die Trennung von Definition und Deklaration halte ich für unsinnig. Ich glaube in C++ ist das nur dabei damit man Präprozessor-Direktiven benutzen und sich um doppelte Includes sorgen muss ;).
Nein mal im Ernst auch in Obejctive-C nützt mir die trennung von Definition und Deklaration wenig. Es sorgt höchstens dafür, dass ich doppelt so viele Dateien hab und immer nachschauen muss was ich jetzt eigentlich alles so definiert habe... Dass das ganze nicht gerade praktisch ist oder mehr Übersicht spendet, ist doch spätestens durch die Abschaffung in C# bewiesen :).

Pro Datei eine public Klasse sorgt übrigens tatsächlich für mehr Überblick (im gegensatz zur Trennung von Definition und Deklaration :D). Man kann den Dateibaum ja dann praktisch schon als Typ/Klassen-Überblick benutzen und braucht so noch nicht mal eine IDE um einen Überblick zu bekommen - ganz im gegenteil zum teils heftigen Definitions- und Deklarationssalat in C++. <edit>hab gerade gesehen dass ich in einem post vorher teilweise schon darauf geantwortet hatte und mich hier also wiederhole... sorry :)</edit>[/size]

Ja, für C++ müsste es theoretisch auch gewrappt, gekapselt und schick verpackt werden. Praktisch tut das aber scheinbar kaum jemand, weil es mit der C-Abwärtskompatibilität ja schon irgendwie geht … da kommt dann auch der schlechte Ruf her.

Und das ist das große Problem, dass ich mit C++ habe: Die tückische Nähe zu C, die Formlosigkeit mit der man programmieren kann und die meist dementsprechend nervig programmierten Bibliotheken. In Java ist das alles viel einheitlicher und ordentlicher. Vielleicht steckt dann hinter dieser formalen einheitlichen Ordnung semantisch großes Chaos, aber das ist in jeder Programmiersprache so.

[Lord Delvin]

Mein Problem mit dem Garbage-Collector der VM war eher ein anderes. Ich hätte gerne mehr Speicher freigegeben, da ich gemerkt habe das mein Arbeitsrechner sehr langsam wurde, der Garbage-Collector schien aber der Meinung zu sein, dass das noch nicht nötig ist (Ich habe lange danach gesucht, ob das Objekt auch wirklich frei gegeben wurde, oder irgendwo noch versteckt referenziert wurde, habe aber nichts finden können.)

Ich glaub du hast noch nicht verstanden, wie Speicher wirklich funktioniert, sonst würde dich das nicht wundern. Der Java GC dürfte wohl der beste sein, dens atm gibt. Wenn der bei nem gc Aufruf, der im übrigen eigentlich immer nutzlos sein sollte, irgendwas nicht einsammelt, dann nur, weil es nicht möglich ist, d.h. es gibt noch ne Referenz auf das Objekt. Wenn du garantierst, dass es keine null-Pointer Exception gibt, wenn du auf eine Referenz zugreifst, auf die die schonmal erfolgreich zugreifen kannst, dann kannst du ein Objekt auch erst wegräumen, wenn es keine Referenz mehr auf das Objekt gibt.
Wenn du erlauben würdest Objekte manuell zu löschen würde das einfach schief gehen. Sieht man ja an schlechtem C(++) code.

Das ganze war dann ein typischer (C++ Anfänger) Fehler, der mir schnell vor Augen geführt hat was ich an Sprachen wie Java so mag:

Code: Alles auswählen

//In der Header-Datei:
GLushort *indices;
//im constructor in der Header-Datei:
indices=new GLushort[numIndices];
//in der Funktion loadVBO in der cpp datei:
glGenBuffers(1, &vboIndicesName);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, vboIndicesName);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, numIndices*sizeof(GLuint), &indices[0], GL_STATIC_DRAW);

Der Code besteht nur aus C. Wenn du in C++ sizeof schreiben musst, hast du eigentlich immer was falsch gemacht. Btw würde dir das n memorychecker ziemlich schnell verraten, dass das böse ist. Und meistens sagt dir der memorychecker, wenn du n bug oder n memoryleak hast(was eigentlich auch n bug ist), warum bzw. welche Zeilen Code man sich nochmal ansehen möchte.

Im übrigen find ichs echt interessant, wie schnell hier gepostet wird.

[Stephan Theisgen]

@Lord Delvin:

Ich glaub du hast noch nicht verstanden, wie Speicher wirklich funktioniert, sonst würde dich das nicht wundern.

Danke für die Blumen 8-) Das lass ich jetzt mal unkommentiert, ich habe definitiv keine Lust meine Kentnisse über Speichermanagment darzustellen...

Auch wenn's nicht mehr ganz hier her gehört und ich definitiv zu wenig über die interne Implementierung des GC in Java kenne, so vermute ich das der Grund war, das ich den Speicher immer wieder genau in der Größe gebraucht habe und er sich dann vielleicht als interne Optimierung überlegt, hey wieso freigeben, da ist noch genug da im System und der braucht den gleich ja sowieso wieder... Das ist in fast 100% der Fälle auf fast jedem PC richtig, nur bei mir auf der Arbeit eben nicht, mein Rechner zuhause konnte das ohne Probleme ab.

Im übrigen find ichs echt interessant, wie schnell hier gepostet wird.

Ich auch, und die Resonanz überwältigt mich, aber so langsam wiederholen sich die Argumente, teilweise wirds persönlich. Ich denke ich werde den Thread bald schließen "lassen". Bevor noch ein Unglück in dieser Forumsgemeinde passiert :mrgreen: Es hat mir jedenfalls mal ein paar Argumente für und gegen Java und C++ gebracht und erstaunlicher weise sogar begründete... Außer das andere Sprachen kaum erwähnt wurden, als ob nur die Welt Java vs. C++ existiert...

[Ingrater]

Ich denke ein großes Faktor ist auch, dass man mit C++ einfach besser angeben kann. Wenn man ein bisschen template-meta programming code rumzeigt halten einen die Meisten gleich für einen Halbgott ^^

[Chromanoid]

Ich auch, und die Resonanz überwältigt mich, aber so langsam wiederholen sich die Argumente, teilweise wirds persönlich. Ich denke ich werde den Thread bald schließen "lassen". Bevor noch ein Unglück in dieser Forumsgemeinde passiert Es hat mir jedenfalls mal ein paar Argumente für und gegen Java und C++ gebracht und erstaunlicher weise sogar begründete... Außer das andere Sprachen kaum erwähnt wurden, als ob nur die Welt Java vs. C++ existiert...

Hehehe naja hoffen wir mal, dass es nicht soweit kommt ^^.... Ich denke würde man noch mehr Sprachen ins Spiel bringen, würde es schnell ziemlich unübersichtlich.... Ich persönlich sehe das ganze auch eher als Gegenüberstellung der Konzepte: Sprachen inkl. Plattformen wie Java und C# vs. C++. Wobei C++ da in seiner Komplexität recht alleine darsteht, oder?

Letztendlich könnten wir uns doch alle darauf einigen, dass Java nicht wirklich so schlecht ist :), oder? Java hat im Grunde vor allem eine andere Zielgruppe als C++ und ist für diese Zielgruppe wahrscheinlich auch besser geeignet. C++ bedient seine eigene Zielgruppe von OS-Entwicklern, High-End-Spiele- und Hardcore-Programmierern... :)

PS: Witziger Weise gibt es einiges zu dem Thema Java vs. C++ und Java Kritik auch bei Wikipedia :D -->
Criticism of Java
Comparison of Java and C++
Comparison of Java and C Sharp
Comparison of the Java and .NET platforms

[Alexander Kornrumpf]

Als Moderator bin ich eigentlich recht froh, dass es hier mal wieder eine rege Diskussion gibt, wenn auch über ein recht ausgelutschtes Thema. Schließen halte ich für den falschen Weg. Ich bin sicher wir sind alle in der Lage persönliche Angriffe auf ein Minimum zu reduzieren und über die wenigen, die dennoch stattfinden hinwegzusehen.

Die Standardantwort auf deine Frage ist bekanntlich dass es keine beste Sprache gibt sondern nur LISP und eben alle anderen diejenige Sprache die beste ist, mit der Du das aktuelle Problem am schnellsten (wahlweise nachhaltigsten) lösen kannst. Da wir diese Antwort schon kennen sehe ich hier eher eine Austausch über persönliche Vorlieben von Programmiersprachen. Und über Geschmack lässt sich bekanntlich trefflich streiten.

Zur Not könnten wir ja auch gemeinsam über Perl ablästern. Oder mag jemand Perl? :)

[Chromanoid]

Zur Not könnten wir ja auch gemeinsam über Perl ablästern. Oder mag jemand Perl?

gute idee :D wobei perl ja schneller als php ist (oder? :?: )... mmh aber der quelltext ist einfach grausig...

[EyDu]

Ich glaub du hast noch nicht verstanden, wie Speicher wirklich funktioniert, sonst würde dich das nicht wundern. Der Java GC dürfte wohl der beste sein, dens atm gibt. Wenn der bei nem gc Aufruf, der im übrigen eigentlich immer nutzlos sein sollte, irgendwas nicht einsammelt, dann nur, weil es nicht möglich ist, d.h. es gibt noch ne Referenz auf das Objekt.

Doch, den GC manuell anwerfen kann schon etwas bringen und zwar wenn man zyklische Referenzen hat:

x->y->a->b->c->a

Wenn du gerade mit dem Objekt x arbeitest und y freigibst, dann bleibt der Ring a->b->c->a übrig,da jedes Objekt einmal referenziert ist. Der Fall ist natürlich relativ selten, kann aber natürlich nicht ignoriert werden.

Was mich an Java stört ist vorallem die Unterscheidung zwischen Objekten und Basistypen wie int oder float. Man kann zwar Integer und Float verwenden, aber für eine objektorientierte Sprache finde ich diese Differenzierung schon sehr schwach. Noch gravierender finde ich nur die Mentalität, dass der Programmierer vor sich selbst geschützt werden soll. Ich mag ja schon kein public/private/protected in C++, aber mit Java habe ich immer das Gefühl, dass man an allen Ecken und Enden noch weiter beschränkt wird. Ich sage nur "Mehrfachvererbung", Getter- und Setter-Methoden, keine Überladung von Operatoren oder keinerlei Metaprogrammierung. Wobei man letzteres durch Reflection und Annotations doch noch halbwegs gut nachbauen kann.

Ich kenne auch niemanden, der in Java nun besseren Code schreiben würde. Wer in C++ schlechten Code zusammenschreibt, der wird das sicher auch in Java tun. Es hängt am Ende immerhin vom Programmierer ab, sauberen Code zu erzeugen. Und das kann man in C++ genau so gut/schlecht. Wenn ich mich zwischen Pest und Cholera, also Java und C++, entscheiden müsste, dann würde ich wohl immer C++ nehmen. Ok, als Cholera würde ich jetzt C++ nicht bezeichnen, aber es bringt einfach weniger Spaß als andere Sprachen ^^ Also ganz subjektiv ausgedrückt ;-)

Sebastian

[Krishty]

Auch wenn's nicht mehr ganz hier her gehört und ich definitiv zu wenig über die interne Implementierung des GC in Java kenne, so vermute ich das der Grund war, das ich den Speicher immer wieder genau in der Größe gebraucht habe und er sich dann vielleicht als interne Optimierung überlegt, hey wieso freigeben, da ist noch genug da im System und der braucht den gleich ja sowieso wieder... Das ist in fast 100% der Fälle auf fast jedem PC richtig, nur bei mir auf der Arbeit eben nicht, mein Rechner zuhause konnte das ohne Probleme ab.

Ja, so arbeitet der GC tatsächlich. Mich überrascht nur ein wenig, dass man die Gesamtgröße nicht steuern kann … dass die VM z.B. nur die Hälfte des Speichers benutzt, wenn man der Meinung ist, dass man nicht mehr braucht?

Wie sieht das eig mit dem Adressraum in Java aus? Wieviel steht zur Verfügung?

Erinnert mich übrigens ein bisschen an den guten alten Schwächen-von-C++-Thread … :)

[Aramis]

Erinnert mich übrigens ein bisschen an den guten alten Schwächen-von-C++-Thread …

Verdammt, wo sind (Einzigartiger-Smalltalk'er) und (Gelöschter-Benutzer) wenn man sie mal dringend bräuchte um diesen Thread über die 10-Seiten Marke zu heben?

Zum Thema zurück ... wie geht der Java GC nun eigentlich mit zyklischen Referenzen um? Ich weiß dass beispielsweise Python's GC eine spezielle Zusatzlogik integriert um zyklische Referenzen aufzulösen.

[Chromanoid]

Ja, so arbeitet der GC tatsächlich. Mich überrascht nur ein wenig, dass man die Gesamtgröße nicht steuern kann … dass die VM z.B. nur die Hälfte des Speichers benutzt, wenn man der Meinung ist, dass man nicht mehr braucht?

z.B. mit -Xmx256m als parameter für java(.exe) kannst du festlegen, dass die java vm für das programm einen arbeitsspeicher von 256m hat...

[Jörg]

wie geht der Java GC nun eigentlich mit zyklischen Referenzen um?

Es gibt nicht "den" JAVA GC. Alleine die VM von SUN bietet einige Moeglichkeiten zur Algorithmenauswahl. Wenn man soweit ist, dass man daran schrauben muss, ist es mit der "Platformunabhaengigkeit" eh vorbei, jede VM braucht dann ihr eigenes Tuning.

http://java.sun.com/javase/technologies ... ing_6.html