XCode im Allgemeinen

[MacApple]

Das liegt nicht am Programmierer.. bzw nicht unbedingt, aber wenn Du mit einem Java-Desktop-Programm arbeitest, dann kann es schon langsam wirken. Das liegt aber vielmehr an z.B. Swing als nun an Java selbst. Für GUI-Anwendungen ist Java wirklich nicht der bringer, aber das würde ich mal eher aus Swing-Framework schieben als auf Java an sich.

Ich glaube nicht, dass diese Anwendungen auf das Swing-Framework aufsetzen.

MacApple

 

[Cyrics]

@Cyrics: Wenn Du glaubst, dass XCode 'überladen' sei, dann schau dir mal eclipse an... da kriegst Du das kalte Grausen. Eine IDE, die genau nur deinen Bedarf abdeckt, nicht mehr und auch nicht weniger, wirst Du nicht finden.

Das der Befehlssatz von Java "aufgebläht" sei verstehe ich nicht so ganz.... oder meinst Du die Frameworks die da mit kommen?

Mit meinem geringen Verständnis darüber würde ich sagen, dass es am Befehlssatz direkt liegt. Also ein guter Vergleich dazu ist sicher CISC und RISC-Prozessoren. Beide unterscheiden sich einfach grundlegend durch ihren mitgelieferten Befehlssatz und deren Anwendungen.
Java würde ich nun mit einem CISC-Prozessor gleich setzen und C++ mit einem RISC.
Es ist einfacher mit Java zu programmieren weil einem ein größerer Befehlssatz vorliegt aber auch eine Menge Karteileichen und man hat hier immer das Gefühl nur an den oberen 20% zu kratzen obwohl man alles ausreizen mag.
C++ setze ich mit einem RISC-Prozessor gleich... es mag umständlich sein zu programmieren, man muss sich einen eigenen Stil ausarbeiten, komplexe Probleme einzeln aufbröseln und in Teilprobleme zerlegen etc. und ein riesen Aufwand treiben für ein paar kleinere Dinge. Dafür hat man den kompletten Befehlssatz ausgeschöpft und ein "schlankes" System.

Nun mag jeder für sich seine Vor- oder Nachteile daraus ziehen.
Ich mag die bequeme Art und Weise und mag daher Java doch sehr, aber sehe es eben als aufgebläht an.

Ist aufgebläht nun klar? Dabei ist es unabhängig vom Framework in meinen Augen. Zumindest seh ich nicht wieso es für diesen Zustand verantwortlich sein sollte.

PS: übrigens kenn ich Eclipse gut, aber es läuft sehr bescheiden und meinen Verhältnissen auch nicht angemessen genug. Mir gefällt XCode auch besser als Eclipse, aber ich hab ständig das Gefühl ich weiß eigentlich gar nichts über XCode und würde gerne mehr darüber lernen, das ärgert mich
(mal eben bei amazon nach Büchern gucken)

 

[tjp]

Mag sein das Java am Desktop noch nicht richtig angekommen ist und einigen Overhead mitbringt, aber wenn du mir keine Alternative für die schnelle und sichere Entwicklung skalierender Server/Webapps nennst kann ich dich leider nicht ganz ernst nehmen ...

Java hat einige üble Designfehler. Erstens das sklavische Festhalten am GarbageCollection, das führt bei großen Anwendungen zu einem massiven Speicheroverhead der extrem teuer ist. Speicher für einen großen Server kostet richtig Geld. Wenn man statt einer kleinen 4 CPU SUN eine Midrange SUN mit 12 CPUs hinklotzen muß ist das ein nicht unerheblicher Kostenfaktor.

Zweitens das explizite Freigeben von Resourcen (nicht nur Speicher) im Fall eines Auftretens einer Exception. Das ist enorm fehlerträchtig, da man ständig wissen muß, was eine Klasse intern eigenlich tut. RAII unter C++ verlagert das Problem in das Design der Klasse, so daß man hier bei konsequenter Anwendung sehr viel weniger Fehlerquellen hat. Und man belegt deutlich weniger Resourcen während der Laufzeit des Programms.

Der einzige Vorteil von Java sind die Unzahl an Frameworks, die mitgeliefert werden. Dadurch ist es leichter als mit C++ eine Client- Server-Applikation zu entwicklen. Bei C++ muß man die Frameworks aus verschiedenen Quellen nutzen, was zu Problemen führt. Allerdings gibt es für fast alles eine OpenSource-Lösung.

Eine kommerzielle Alternative zu Java ist auch IBMs Visual SmallTalk, eine Enterprise Computing Lösung auf Basis von SmallTalk. Steht J2EE in nichts nach.

 

[tjp]

C++ setze ich mit einem RISC-Prozessor gleich... es mag umständlich sein zu programmieren, man muss sich einen eigenen Stil ausarbeiten, komplexe Probleme einzeln aufbröseln und in Teilprobleme zerlegen etc. und ein riesen Aufwand treiben für ein paar kleinere Dinge.

Das ist nur der Fall, wenn man kein passendens Framework verwendet, bei einigen Sachen muß man erst selbst Hand anlegen, bei anderen gibt es fertige Frameworks. Die Vielzahl der Frameworks für Java haben aber auch Probleme mit der Einheitlichkeit erzeugt.

Der Hauptunterschied bei beiden Sprachen ist eine andere Designphilosophie für Programme. In C++ kapselt man Resourcen komplett in den Klassen weg, in Java kann man das auf Grund des nichtdeterministischen Aufrufverhaltens für "Destruktoren" nicht machen, man muß das "finally" Konstrukt benutzen. Die Verlagerung der Resourcenverwaltung heraus aus dem Klassendesign in den Anwendungscode ist problematisch und fehlerträchtig. Aus Sicht des C++ Programmierers ist das ein gewaltiger Rückschritt.

 

[MatzeLoCal]

Ich glaube nicht, dass diese Anwendungen auf das Swing-Framework aufsetzen.

MacApple

Was sind das denn für Anwendungen?

Ist aufgebläht nun klar? Dabei ist es unabhängig vom Framework in meinen Augen. Zumindest seh ich nicht wieso es für diesen Zustand verantwortlich sein sollte.

Nein.. ich bin nun verwirrter als vorher was du nun mit "aufgeblähtem Befehlssatz" meinst. Mach doch mal ein konkretes Bespiel.

PS: übrigens kenn ich Eclipse gut, aber es läuft sehr bescheiden und meinen Verhältnissen auch nicht angemessen genug. Mir gefällt XCode auch besser als Eclipse, aber ich hab ständig das Gefühl ich weiß eigentlich gar nichts über XCode und würde gerne mehr darüber lernen, das ärgert mich
(mal eben bei amazon nach Büchern gucken)

Ich muss hier meist mit eclipse arbeiten... liegt auch daran, dass XCode bestimmte Dinge (java-technisch) nicht kann... aber wenn ich hier was eigenständiges Programmieren darf, dann ist XCode meist 1. Wahl.

 

[MacMark]

tjp, was du da über Java schreibst, ist falsch.

a) "finally" hat nichts mit "Destruktoren", die es bei Java nicht gibt, zu tun, sondern ist Teil der try-catch-finally-Kombination zum Exception-Fangen.
b) Du meinst möglicherweise das Gegenteil der Konstruktor-Methode, die jedoch finalize() heißt und nicht vergleichbar ist mit Destruktoren in C++, da Java die Garbage-Collection (GC) vornimmt. Finalize() wird von der GC aufgerufen beim gcen des Objects und diese Methode wird nur dann implementiert, wenn das Object Resourcen hält, die etwas anderes als Hauptspeicher darstellen, beispielsweise Netzwerkverbindungen und offene Dateien. Finalize() dient also lediglich dazu, Netzwerkverbindungen und Dateien zu schliessen, die das Object geöffnet hat und die man am beim GCen des Objects mit schliessen möchte.
c) Wenn keine Referenz mehr auf ein Object besteht, dann wird von der GC frühestens der Speicher dafür bereinigt. Daran ist nichts Fehlerträchtiges, da du unter Java keinen selbstangelegten Zeiger auf die Speicherstelle direkt nutzen kannst und durch Wegfall der letzten Java-Referenz definitiv nie wieder auf diesen Speicher zugreifen kannst.
d) Problemtisch ist bei C++, daß der Programmierer Destruktoren explizit schreiben muß und daher eventuell Speicher nicht wieder freigegeben wird, weil er etwas vergißt. Dieses Szenario schließt Java vollkommen aus. Daher ist C++ aus Sicht des Java-Menschen Steinzeit.

 

[commander]

Juhuu! ATTAAAACKE!!

Ich kann nur wieder mein altes Argument bringen: In einem Projekt mit 50+ Entwicklern dankst Du jeden Abend dem Java.gott() für die Erfindung der Garbage-Collection. Denn man kann selbst in Java noch Memoryleaks produzieren - wenn man sich bemüht. Seit der 1.4 arbeitet die GC sehr effizient, Applicationserver setzen ja z.B. unbedingt auf dieses Feature - und selbst ein FullGC ist inzwischen so schnell, dass es die gehostete Applikation nicht beeinträchtigt. Ich möchte garnicht daran denken, was für Probleme auftreten würden, wenn sich alle Entwickler selbst um das wegräumen ihrer Objekte kümmern müssten - Hölle.

Tatsächlich: Durch die Verwendung der verschiedenen Speicherbereiche (New-, Tenured-, und Permanent) ist der Speicherbedarf höher als in anderen objektorientierten Sprachen.

Aber: Was kostet Speicher im Vergleich zu Arbeitszeit? Und Java ist nun einfach für grosse Client/Server-Applikationen in der Entwicklung sehr effizient.

btw: GUI: Unsere Software verwendet ein eigenes Look&Feel mit Transparenzen und anderen nicht-Standardfeatures wie Touchbuttons, die nicht rechteckig sind, sondern jeweils zwei sich sozusagen umarmen - und das alles zeichnet sich sehr fix. Wenn man fit in Swing ist, kann man damit durchaus schnelle, reaktionsfreudige GUIs bauen. Leider ist das nicht out of the box so. Da bringt Swing für den Anfänger eine trügerische Sicherheit.


Zum Thema: als IDEA-Anwender bin ich leider abhängig und finde XCode im Feature-Vergleich nicht mal erwähnenswert. Sorry. Für Objective-C ist das sicher anders.

Gruß,

.commander

 

[MatzeLoCal]

Der Hauptunterschied bei beiden Sprachen ist eine andere Designphilosophie für Programme. In C++ kapselt man Resourcen komplett in den Klassen weg, in Java kann man das auf Grund des nichtdeterministischen Aufrufverhaltens für "Destruktoren" nicht machen, man muß das "finally" Konstrukt benutzen. Die Verlagerung der Resourcenverwaltung heraus aus dem Klassendesign in den Anwendungscode ist problematisch und fehlerträchtig. Aus Sicht des C++ Programmierers ist das ein gewaltiger Rückschritt.

Ich kann hier MacMark nur zustimmen: Du hast finally nicht verstanden!

 

[MatzeLoCal]

Ich möchte garnicht daran denken, was für Probleme auftreten würden, wenn sich alle Entwickler selbst um das wegräumen ihrer Objekte kümmern müssten - Hölle.

Aber es wäre auch ein nicht zu unterschätzender Vorteil, wenn mensch auch die Möglichkeit hätte, Objekte explizit "wegzusprengen" .. oder zumindest die GC damit zu beauftragen und am Ende auch die Gewissheit zu haben, dass das Objekt nun wirklich weg ist.

Wir hatten hier schond das Problem, dass die GC auch nach "nullen" nicht weggeräumt hat, weil sie der Ansicht war, dass da noch eine Referenz drauf hängt.
Da waren (und sind) die max 2 GB auch mal zu wenig.

btw: GUI: Unsere Software verwendet ein eigenes Look&Feel mit Transparenzen und anderen nicht-Standardfeatures wie Touchbuttons, die nicht rechteckig sind, sondern jeweils zwei sich sozusagen umarmen - und das alles zeichnet sich sehr fix. Wenn man fit in Swing ist, kann man damit durchaus schnelle, reaktionsfreudige GUIs bauen. Leider ist das nicht out of the box so. Da bringt Swing für den Anfänger eine trügerische Sicherheit.

Jup, Swing reaktionsfreudig zu gestalten ist durchaus möglich. Allerdings verlagern sich dann nur die "Probleme". Es ist halt ein abwägen was mensch benötigt. Aber dass an der GUI was passieren muss hat SUN ja scheinbar selbst gemerkt.. siehe Java6

 

[MacMark]

... dass die GC auch nach "nullen" nicht weggeräumt hat ...

Das ist normal, denn die GC findet nicht zwangsläufig sofort statt, wenn keine Ref mehr existiert. Sie findet statt, wenn die anderen Prozesse ihr Zeit lassen. Wenn allerdings Speicherplatz knapp wird, wird die GC trotz wichtigerer Prozesse durchgeführt.
Die GC ist je nach VM etwas anders implementiert.

 

[MatzeLoCal]

Das ist normal, denn die GC findet nicht zwangsläufig sofort statt, wenn keine Ref mehr existiert. Sie findet statt, wenn die anderen Prozesse ihr Zeit lassen. Wenn allerdings Speicherplatz knapp wird, wird die GC trotz wichtigerer Prozesse durchgeführt.
Die GC ist je nach VM etwas anders implementiert.

Nach System.gc() wird aber z.B. explizit aufgeräumt. Und selbst nach Tagen sollte die GC 'eigentlich' den Speicher eines genullten Objects freigeben... oder?

Glaub mir.. wenn ich sage, dass die GC nicht immer funzt wie sie soll bzw wie es von ihr erwartet wird, dann weiss ich schon was ich sage.

 

[tjp]

tjp, was du da über Java schreibst, ist falsch.

Nein, keineswegs.

a) "finally" hat nichts mit "Destruktoren", die es bei Java nicht gibt, zu tun, sondern ist Teil der try-catch-finally-Kombination zum Exception-Fangen.

Doch "finally" hat sehr viel mit den nichtexistenten Destruktoren zu tun! Man muß "finally" benutzen, damit es keine Resourcenlecks gibt. Wenn man Destruktoren hat braucht man "finally" nämlich gar nicht.

Ein Beispiel in Pseudocode (leg die Syntax nicht auf die Goldwaage)

// Database ist eine Klasse die, die irgend ein Datenbankhandle verwaltet
// erst mal den RAII Ansatz

Anfang einer Methode {
  Database db (...); // irgend ein Konstruktoraufruf der eine DB Verbindung öffnet
  // Punkt A
  ... // beliebiger Code der eine Exception werfen darf
  // Punkt B
} // <- hier wird db automatisch destruiert und vernichtet

Sollte zwischen A und B eine Exception auftreten, dann wird db automatisch vernichtet und alle Resourcen freigegeben. Ein try{} catch{} Block ist nur dann notwendig, wenn man an dieser Stelle überhaupt die Exception behandeln kann. Wenn das nicht der Fall ist läßt man ihn einfach weg.

Anfang einer Methode {
  Database db (...); // irgend ein Konstruktoraufruf der eine DB Verbindung öffnet
  try {
    ... // beliebiger Code der eine Exception werfen darf
  }
  finally {
    db.dispose (); // hier muß die DB explizit geschlossen werden
  }
}

Hier haben wir wieder das alte Problem der expliziten Verwaltung von Resourcen, so wie das in C, Pascal etc. mit Speicher mit new/delete, malloc/free etc. der Fall ist. Man muß explizit etwas tun, damit ist es weitaus gefährlicher, da man sehr viel leichter die explizite Freigabe von Resourcen vergessen kann.

Das C++ RAII Idiom verwendet im Anwendungscode die implizite Freigabe von Resourcen, so daß man nur im Konstruktor, Destruktor, Zuweisungsoperator und dem Kopierkonstruktor aufpassen muß. Und das gilt auch nur dann, wenn man Resourcen selbst verwalten muß. Klassen höherer Abstraktionsebenen haben dieses Problem meist gar nicht.

d) Problemtisch ist bei C++, daß der Programmierer Destruktoren explizit schreiben muß und daher eventuell Speicher nicht wieder freigegeben wird, weil er etwas vergißt. Dieses Szenario schließt Java vollkommen aus. Daher ist C++ aus Sicht des Java-Menschen Steinzeit.

Einen Destruktor zu schreiben, vergißt nur ein Java-Programmierer, der blutiger Anfänger in C++ ist. Sonst passiert das garantiert nicht. Allerdings mußt Du mit Java jedensmal, wenn du ein Objekt verwendest finally{foo.dispose();} hinschreiben. Vergißt Du es auch nur ein einziges mal, hast Du ein Resourcenleck.

Das Problem kennen wir doch woher. Ja genau, explizite Speicherverwaltung wurde als so fehlerträchtig betrachtet, daß man GC einführte. Aber diese explizite Verwaltung von Resourcen soll für andere Resourcen zeitgemäß sein?

 

[tjp]

Ich kann hier MacMark nur zustimmen: Du hast finally nicht verstanden!

Ich denke, daß Du nicht weißt was RAII ist.

 

[tjp]

Aber es wäre auch ein nicht zu unterschätzender Vorteil, wenn mensch auch die Möglichkeit hätte, Objekte explizit "wegzusprengen" ..

Programmiert Ada oder C++ dann habt ihr diese Probleme nicht mehr. Java krankt nun einmal an seinem GC, da es keine saubere Kontrolle über die Lebenszeit von Objekten erlaubt und das ist schlecht.

Mit RAII bekommt man das Resourcenproblem sehr zuverlässig in den Griff, insofern ist das Fehlen eines eingebauten GCs (man kann natürlich welche in Form einer Library benutzen) kein Problem.

 

[MatzeLoCal]

Ich kann hier MacMark nur zustimmen: Du hast finally nicht verstanden!

Ich denke, daß Du nicht weißt was RAII ist.

Das eine hat mit dem anderen nichts zutun! Das was Du über finally in Java geschrieben hast stimmt nicht. finally ist teil des try/catch und hat nichts mit dem destructor einer Klasse zutun.

Und jap, ich kenne RAII nicht.. muss ich aber auch nicht, wenn ich über Java spreche.

 

[MacMark]

tjp, du hast N-U-L-L Ahnung, was finally in Java bedeutet. Es hat N-U-L-L mit Destruktion von Objekten zu tun. Ich hätte nicht gedacht, daß dieser Satz mal angebracht wäre, aber hier ist er es wirklich: Informier dich erstmal bevor du hier absoluten Unfug schreibst. Du hast keine Ahnung von Java. Nicht für 5 Pfennig!

 

[tjp]

Das eine hat mit dem anderen nichts zutun! Das was Du über finally in Java geschrieben hast stimmt nicht. finally ist teil des try/catch und hat nichts mit dem destructor einer Klasse zutun.

Java kennt keinen echten Destruktor (finalize() erfüllt die Bedindungen eines echten Destruktors nicht), eben deshalb braucht es "finally". In Java kann es deshalb auch keine Abhängigkeit von "Destruktoren" und Exceptions geben, weil es keinen deterministischen Zusammenhang zwischen beiden gibt.

Unter anderem in C++ ist das aber der Fall. Daher hängen dort auch Exceptions und Destruktoren unmittelbar voneinander ab. Wenn man eine Exception nicht in einem try{} catch{} Block behandelt wird die Exception propagiert und beim Verlassen des Codeblock alle Objekte auf dem Stack destruiert, genauso als ob man regulär den Codeblock verlassen würde, d.h. ihre Destruktoren werden ausgeführt, und somit deren Resourcen (Stichwort RAII) wieder freigegeben.

Ergo, "finally" braucht es nicht, da "finally" keinerlei Nutzen in C++ hat. Der Nachteil von "finally" ist aber, daß man überall in den Programmcode "finally" Statements einfügen muß, d.h. man hat eine explizite Resourcenverwaltung. Und exakt daran krankt Java. Implizit aufgerufene Destruktoren sind expliziten "finally"-Statements überlegen, da man bei ersteren sich nicht darum kümmern muß, wann sie aufgerufen werden müssen, das macht schon der Compiler/Laufzeitumgebung in einer deterministischen Art&Weise.

 

[MacMark]

Im finally-Block muß eine DB-Verbindung nicht explizit geschlossen werden. Der Garbage-Collector ruft close() automatisch auf. Und fatale Fehler lösen ein close() ebenfalls automatisch aus. Der explizite Aufruf von close() auf einer Connection dient nur dem beschleunigten Schließen. Und das macht man auch nur bei Netzwerk- und Datenbank-Verbindungen.

Du bist dermaßen in C++ verhaftet, daß du dich offensichtlich nicht in Java reindenken kannst. Echt schlimm.

 

[slayercon]

Langer Thread mittlerweile aber eine brauchbare Alternative für J2EE/Web Projekte hat mir auch keiner von den Java Bashern nennen können ... schade eigentlich ..

Aber es ist ja noch nicht zu spät ...

 

[MacApple]

Was sind das denn für Anwendungen?

Ziemlich spezielle. Managementsoftware für Netzelemente (Access-Nodes).

MacApple