XCode im Allgemeinen

[MatzeLoCal]

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.

Sag mal, hast Du schonmal Java-Code gelesen????

Ich gebe dir mal ein Beispiel für finally:
(pseudo code!!!)

private void schreibeStringInDatei(String einString) {
 
 
 try {
    //Datei öffnen
    //einString in die Datei schreiben
  } catch(Exception ex) {
    //Hier is zutun, was bei einem fehler eben zu tun ist
  } finally {
    //Datei schliessen
  }

Was hier passiert ist nur eines, nach am Ende des try/catch-Blocks wird das was in finally steht ausgeführt. Ganz egal, ob das schreiben in die Datei auf einen Fehler lief oder ob es ordungsgemäß ablief. DAFÜR wird finally verwendet. Finally ist nur optional.. die Datei hätte auch ausserhalb des blocks geschlossen werden können.. aber das ist eine andere geschichte... achja.. und bevor die Kritik kommt, dass auch das Schliessen der Datei auf Fehler läuft .. jap... richtig.. aber das tut zum Verständnis des Beispiels nichts zur Sache.

Zum besseren Verständnis von Exceptions in Java ... das ist das mit dem finally

 

[MatzeLoCal]

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 ...

Oh.. hab ich was verpasst? Was für eine alternative?

 

[MatzeLoCal]

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

Ich wollte nur wissen ob es da ne GUI gibt?
Von wegen Swing, u know...

 

[MacApple]

Ich wollte nur wissen ob es da ne GUI gibt?
Von wegen Swing, u know...

Ja, ist mit GUI.

MacApple

 

[MatzeLoCal]

Ja, ist mit GUI.

MacApple

Wie gesagt, dann denke ich mal, dass es Swing oder SWT nutzt... und beides ist nicht so der bringer..

 

[MacApple]

Wie gesagt, dann denke ich mal, dass es Swing oder SWT nutzt...

Könnte ich das irgendwie feststellen, ohne den Quellcode zu haben?

MacApple

 

[tjp]

Im finally-Block muß eine DB-Verbindung nicht explizit geschlossen werden.

Mir ist sehr wohl bewußt, das durch den "finally" Block keine Objekte zerstört werden sondern dies zu einem späterem Zeitpunkt, der durch den GC bestimmt wird, erfolgt. Nichtsdestoweniger muß man "finally" benutzen, wenn man resourcenschonend programmieren will,da "finalize()" irgend wann ausgeführt wird. Wenn man z.B. eine eng begrenzte Anzahl DB-Verbindungen hat, dann darf man sie nicht willkürlich verschwenden. Jede Verzögerung zwischen der Nichtmehrbenutzung eines Handles und desssen Freigabe kann zu Resourcenknappheit führen, und das ist in vielen Fällen inakzeptabel.

Den GC ständig für einen Collectorlauf zu triggern, ist der Gesamtperformance des Systems nicht unbedingt zuträglich, so daß man von solchen Maßnahmen nur behutsam Gebrauch machen sollte. Das führt unter dem Strich dazu, daß Java einen deutlich größeren Resourcenverbrauch hat, als dies mit vergleichbaren anderen Programmiersprachen wie etwa Ada oder C++ der Fall ist.

Wenn man sich auf Grund der Infrastruktur (J2EE, Tools, ...) und der vielen Frameworks für Java entscheidet ist dies ein legitimes Anliegen, nur sollte man es akzeptieren, daß man keine direkte Kontrolle über den Speicher hat, es ist halt ein "Feature" von Java, und für die resourcenschonende Verwaltung von Resourcen Mehrarbeit aufbringen muß. Unschön, aber der einzig gangbare Weg in Java.

 

[MacMark]

Wenn du Resourcen sparen möchtest, dann sei doch konsequent und mach Assemblerprogrammierung.
Direkte Kontrolle über den Speicher? Drauf gepfiffen! Bei Java kann man sich auf die Geschäftslogik konzentrieren und spart sich das Gerödel mit Speicherfreigeben a la C++. Mit Java kannst du keine Speicherlecks produzieren. Bitte nicht verwechseln mit Speicherverbrauch

 

[MatzeLoCal]

Mit Java kannst du keine Speicherlecks produzieren.

Das stimmt nicht...!

 

[MacMark]

MatzeLoCal, dann mach mal ein Beispiel. Bin gespannt. Wie willst du denn in Java einen Speicherbereich reservieren und ihn nicht mehr nutzen können während er weiterhin reserviert bleibt für dich trotz Garbage Collection?

 

[MatzeLoCal]

MatzeLoCal, dann mach mal ein Beispiel. Bin gespannt. Wie willst du denn in Java einen Speicherbereich reservieren und ihn nicht mehr nutzen können während er weiterhin reserviert bleibt für dich trotz Garbage Collection?

Ich selbst muss den Speicherbereich nicht reservieren, das geschieht vom System. Und wenn die GC den Speicher nicht freigibt, bleibt der Bereicht "dicht". Also wird hübsch 'neuer' Speicher allokiert... und dann kommt eines schönes Tages java.lang.OutOfMemoryError .... und das bei 1.5GB zugewiesenen Speicher! Und dabei wurde sogar explizit genullt! Den Code kann ich dir leider nicht zeigen, weil der nicht "mir" gehört.

Literatur zum Thema: MemoryLeak in Java

Sich blind der GC anzuvertrauen ist ungesund, darum bin ich auch skeptisch was da mit ObjC 2.0 kommt, wobei die GC da ja anders funktionieren soll.

 

[MacMark]

Ich selbst muss den Speicherbereich nicht reservieren, das geschieht vom System.

Eben, darauf habe ich angespielt.

Und wenn die GC den Speicher nicht freigibt, bleibt der Bereicht "dicht". Also wird hübsch 'neuer' Speicher allokiert... und dann kommt eines schönes Tages java.lang.OutOfMemoryError .... und das bei 1.5GB zugewiesenen Speicher! Und dabei wurde sogar explizit genullt!

"Trotz 1,5 GB Speicher für Java". Pfffffffffffffff. Nicht "trotz", sondern "wegen" viel Speicher.

a) Solange die VM reichlich Speicher hat, besteht für sie keine Eile, Speicher freizugeben.

"Obwohl explizit genullt". Nochmal pfffff. Siehe a). Und:

b) Solange keine akute Speichernot besteht, ist die Garbage Collection als Prozeß mit niedriger Priorität zu verstehen.

Ich habe mir nach dem Zufallsprinzip drei Beispiele von deinem Link angesehen. Was die dort besprechen, sind keine Memory Leaks, weil sie weiterhin Referenzen auf die Objekte halten, obwohl sie sie nicht mehr benutzen wollen im weiteren Ablauf. Das ist einfach schlechter Programmstil. Sie sammeln beispielsweise lokal (in einer Methode ausschließlich) benutzte Daten in einem static (!) Vector der Klasse. Ich meine, wenn ich Brötchen will, gehe ich zum Bäcker. Wenn ich ein Programm will, sollte ich mich auch an Profis wenden und nicht an irgendwelche Schmierbubis. Warum sie über so einen Blödsinn "Memory Leak" drübertiteln, das weiß nur Gott oder das kranke Hirn, dem die Definition von Speicherlecks nicht klar ist.

 

[MatzeLoCal]

Dann erkläre mir bitte was es war, wenn nicht ein MemoryLeak, wenn der ApplicationServer nach nichtmal einer Woche 1.5GB verbraucht hatte und die GC diesen auch auf Befehl nicht frei machte... wie gesagt, der Code war nicht von mir. Und ob nun SAP oder der externe Entwickler, der, wie gesagt, alles möglich getan hat und die Verbindungen zu vernichten, zu den Schmierbubis gehört, überlasse ich mal Dir.

 

[MacMark]

Dann erkläre mir bitte was es war, wenn nicht ein MemoryLeak, wenn der ApplicationServer nach nichtmal einer Woche 1.5GB verbraucht hatte und die GC diesen auch auf Befehl nicht frei machte... . ...

Das ist doch ganz logisch: Da werden wohl im Laufe der Zeit immer neue Objekte angelegt und auf relativ viele davon existiert offensichtlich mindestens noch eine Referenz.

Welche (nicht immer leicht nachträglich zu findenden) Programmierfehler das sein können, zeigt ja dein obiger Link mustergültig.

Eventuell liegt ein entsprechender Programmierfehler auch in den verwendeten Java-SAP-Connector-Klassen von SAP SAP ist ja eher firm in ABAP als in Java.

Ansonsten kann man mit JConsole auch Apps auf JBoss überwachen bezüglich Speicher. Ob es auch mit SAPs J2EE-Server geht, weiß ich nicht.

 

[MatzeLoCal]

Das ist doch ganz logisch: Da werden wohl im Laufe der Zeit immer neue Objekte angelegt und auf relativ viele davon existiert offensichtlich mindestens noch eine Referenz.

Welche (nicht immer leicht nachträglich zu findenden) Programmierfehler das sein können, zeigt ja dein obiger Link mustergültig.

Die Verbindungen waren geschlossen! Es konnte darüber auch keine Verbindung aufgebaut werden, nur die GC gab den Speicher nicht frei!

Wie gesagt in diesem Fall bleibe ich dabei, dass es eine MemoryLeak war und die Links aus dem JavaWiki dokumentieren das auch.
Aber ich werde hier nicht mehr weiter diskutieren, weil ich lernfähig bin und mich ausnahmsweise mal der Sinnlosigkeit unterwerfe.

Ansonsten kann man mit JConsole auch Apps auf JBoss überwachen bezüglich Speicher. Ob es auch mit SAPs J2EE-Server geht, weiß ich nicht.

Die JavaApplicationServer-Welt ist grösser als JBoss und dem SAP J2EE-Server (gibt es den überhaupt.. sorry.. bin da nicht so bewandert was SAP-Server angeht)

 

[tjp]

Wie gesagt in diesem Fall bleibe ich dabei, dass es eine MemoryLeak war und die Links aus dem JavaWiki dokumentieren das auch.

Auch der GC von Java kann Bugs haben. In diesem Fall kann man nur hoffen, daß der Maintainer von Java den Bug behebt.

 

[tjp]

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

Doch, das hatte ich schon getan.
IBM VisualAge SmallTalk, ist definitiv ein adäquater Ersatz für J2EE Lösungen. Alles aus einer Hand und mindestens genauso leistungsfähig.

Wenn man C++ benutzen will, muß man verschiedene Tools kombinieren sofern es OpenSource sein soll und mit kommerziellen Produkten kommt man sehr viel mehr aus einer Hand. Eine einfache Anwort nimm das oder nimm dies gibt es daher nicht. Für Multitier Lösungen ist ACE+TAO+CIAO bestens geeignet, ergänzend muß man die passenden FrameWorks dazunehmen.

 

[MacMark]

Die Verbindungen waren geschlossen! Es konnte darüber auch keine Verbindung aufgebaut werden, nur die GC gab den Speicher nicht frei!

Wie gesagt in diesem Fall bleibe ich dabei, dass es eine MemoryLeak war und die Links aus dem JavaWiki dokumentieren das auch.
Aber ich werde hier nicht mehr weiter diskutieren, weil ich lernfähig bin und mich ausnahmsweise mal der Sinnlosigkeit unterwerfe.

Es müssen nicht unbedingt die DB-Verbindungen sein. Es können irgendwelche Objekte im Code sein, die für ewig referenziert bleiben. Dein JavaWiki zeigt Beispiele für solche Fehler (und keineswegs für MemoryLeaks, obwohl sie die Programmierfehler fälschlicherweise so nennen). Aber rumheulen und engstirnig auf einer einzigen nicht bewiesenen Ursache zu beharren scheint dich mehr zu befriedigen, als nach der wirklichen Ursache zu suchen. Damit bist du offensichtlich weder weiterkommen noch wirst du damit in Zukunft Erfolg haben. Viel Spaß!

Die JavaApplicationServer-Welt ist grösser als JBoss und dem SAP J2EE-Server (gibt es den überhaupt.. sorry.. bin da nicht so bewandert was SAP-Server angeht)

Ach, was! Erzähl mir doch mal etwas, was ich noch nicht weiß.
Es waren nur Beispiele und SAP-Server nenne ich, weil es wahrscheinlich ist, daß ihr den eingesetzt habt für Java bzgl. SAP. Was soll also so eine flappsige, sinnlose Bemerkung? Wenn du wissen willst, mit welchen J2EE-Servern ich gearbeitet habe, konsultiere mein Homepage.

 

[slayercon]

Doch, das hatte ich schon getan.
IBM VisualAge SmallTalk, ist definitiv ein adäquater Ersatz für J2EE Lösungen. Alles aus einer Hand und mindestens genauso leistungsfähig.

Hab mir mal so ein PDF über VAST von IBM gezogen dort wird das Server Smalltalk/ServletInterface als bester Connector zu Webapps beschrieben ... dreimal darfst du raten mit was dieses Modul implementiert wurde ....

 

[MacMark]

Doch, das hatte ich schon getan.
IBM VisualAge SmallTalk, ist definitiv ein adäquater Ersatz für J2EE Lösungen. Alles aus einer Hand und mindestens genauso leistungsfähig. ...

Komisch da IBM doch WebSphere, den eigenen J2EE-Server, so forciert und ziemlich weit vorne mitmischt bei J2EE generell, gelle?