Und wieder am Ziel vorbei.

[MeineMeinung]

Dekonstruktor
====================

Sollte man Ihn wirklich benötigen dann muss man einfach nur

- Die finalize() Methode überschreiben (Denn diese wäre das richtige Pendant zum Destruktor
- Der entsprechenden Objektvariable null zuweisen
- ggf. den GC manuell Starten -> Ist aber normaler weise nicht nötig.

P.S.: Das ganze funktioniert nicht wenn

- man Speicherlecks in seine Software eingebaut hat
- man die finalize() Methode selbst aufruft


--> In vielen Fällen ist dies alles aber garnicht nötig

[kirsche40]

> > > und warum es für Java nur auf die Java Art Sinn macht und zu
> > > schnellen Binärcode (nach dem JIT) führt. Die Leute die sich
> > > C++ und Java ausgedacht haben, haben sich alle was dabei
> > > gedacht!
> > Und deshalb ist Java z.B. nicht IEEE 754 konform. Genau das ist
> > ja das Problem, dass sich die Leute bei Java um bestimmte
> > Probleme herumdrücken.
> Was haben Floating-Point Zahlen mit JIT und GC zu
> tun?
Du hast behauptet, dass die Java-Entwickler sich bei der Entstehung von Java Gedanken gemacht haben, ich habe ein Gegenbeispiel genannt und auf weitere Probleme verwiesen. Außerdem wurde die gesamte Diskussion mit dem Verweis auf fehlende IEEE 754 Konformität eingeleitet.

> > > Programmiersprache Sather zeigt, dass es sinnvoll sein kann,
> > > wenn alle nicht-abstrakten Klassen final sind.
> > Das ist von der OO-Begrifflichkeit her schon Schwachsinn und
> > führt OOP ad absurdum.
> Deswegen sagte ich ja,man sollte auch die VO besuchen. Da erzählt
> er noch viel dazu. U.a. eben was er mit diesen Stichworten auf den
> Folien meint. Eben sinnvoll *für einen gewissen Anwendungsfall*.
Oha. Erinnert mich an eine Vorlesung, wo der Prof seine eigene Sprache 'S' entworfen hat. Dieses "Wir generieren uns eine Sprache für ein spezielles Problem" ist Schwachsinn. Eine Sprache soll viele abstrakte Problemfälle lösen können. Ansonsten ist sie so sinnvoll wie ein Kropf.

> Aber i.d.R. ist Prof. Puntigam auf diesem Gebiet sehr bewandert.
> Hat man irgendeine Frage zu dem Gebiet Programmiersprachen und OOP,
> er weiß die Antwort. Der Kerl kennt scheinbar die Syntax und
> Eigenschaften von zig Sprachen auswendig, auch wenn es rein
> theoretische Konstrukte sind von denen es garkeine Implementierung
> gibt (siehe all die Beispiele auf den Typsysteme Folien).
Hat der Mann auch mal produktiv gearbeitet?

> Aja, die FOOP Folien sind unvollständig, zumal es
> im laufendem Semester unterrichtet wird. Ca. jede
> Woche wird ein Foliensatz dazu kommen.
Hat der Mann auch mal Fachliteratur zum Thema empfohlen?

[raus]

Ich bin auch für Mehrfachvererbung, aber eigentlich ist mir eine bessere Unterstützung für Delegation wichtiger... Naja zum Grund des Posts:
„was OOP ausmacht: Code-Ersparnis durch Vererbung“ Du bist sowas von raus, aber echt.

Und btw. ja manche Entwickler können manchmal besser als die GC abschätzen, wann der Speicher frei gegeben werden kann, dafür geben sie ihn aber auch gerne mal zu früh frei...

[raus]

Und nochmal, Stichwort DSL

[Extrafurz]

kirsche40 schrieb:
------------------
> Mach Dir mal den Spaß und
> programmiere einen Server und einen Client jeweils
> in Java und in C/C++!

LimeWire ist in Java implementiert.

> Die sollen nichts weiter
> machen als 4MB Daten austauschen.

LimeWire schaufelt dir auch gern mehrere Gigabyte an Daten.

> Und dann teste
> mal die Clients gegen die Server auf dem selben
> Host und trace die Kommunikation mit Wireshark
> mit!

Nö danke.

> Da sollte ausschließlich der OS-interne TCP-Stack
> arbeiten.

Unter Unix bleibt einem ohne root-Rechte auch nichts anderes übrig.

> Ist aber offensichtlich nicht so.

Doch.

> Java
> arbeitet so mistig, dass massig Fehler auf der im
> Grunde nicht vorhandenen Leitung entstehen.

Vielleicht entstehen da Timeouts oder die VM hat ungüngstige Voreinstellungen.

> Zusätzlich wird nicht reproduzierbar statt mit
> FIN_ACK mit RST geantwortet.

Wie bitte soll eine Anwendung das beeinflußen können? Es ist völlig egal in welcher Sprache die Anwendung geschrieben ist. Etwas wie tcp::SendFinAck() oder tcp::SendRst gibt es nicht auf Anwendungsebene.

Indirekt kann man so etwas unter Umständen beeinflussen:

RST kann auftreten, wenn die Anwendung nicht zeitig genug mit accept() Verbindungen annimmt und die Warteschlange vollläuft. Das hängt allerdings auch vom OS und dessen Einstellungen ab. Manche sagen dann einfach gar nichts mehr.

shutdown() kann man mit verschiedenen Paramtern aufrufen, die unterschiedliche Semantik und Wirkung haben. Man kann es auch lassen und direkt close() aufrufen.

Es gibt auch diverse OS-abhängige Features zum Einstellen von Timeouts für das akzeptieren oder saubere Schließen von Verbindungen.

SO_KEEPALIVE, das zu gewollten und ungewollten Verbindungsabbrüchen führen kann, gibt es auch noch.

Die Systemaufrufe hierzu kann man ja tracen und so feststellen, was Java - besser gesagt die JDK - hier eventuell anders macht als ein C-Programm.

> Zum Glück ist TCP/IP fehlertollerant...

Das sind wir ja irgendwie alle.

[fachwisser]

Was soll eigentlich dieses Rumgezicke im Forum ?
Java hat kein expliziten GC Befehl, richtig. Das war aber nicht die Kritik.
Kritisiert wurde die Abwesenheit eines Destruktors. Der macht aber keinen Sinn, wenn man nicht weiß, wann dieser ausgeführt wird, weil das Speichermanagement von der VM gemacht wird.

Es ist - egal in welcher Sprache - schlicht guter Stil, wenn man externe Resourcen wie Sockets, Datenbankverbindungen, Filehandles etc. nur solange blockiert, wie man sie benötigt. Daher wäre das Freigeben solcher Resourcen in einem Destruktor meiner Ansicht nach in jedem Fall keine gute Idee.
In diesem Fall würde man nämlich die Verwendung der Resourcen implizit an die Lebensdauer anderer Objekts anhängen.

Da es in Java keine Zusicherung gibt, wann ein Objekt abgeräumt wird, ist es nur zu begrüßen, dass es entsprechend keinen Destruktor gibt.

Man kann meinetwegen bemängeln, dass Java keine explizite Speicherverwaltung kennt - nur ist das in etwa so sinnvoll, wie zu bemängeln, dass Autos in der Regel nicht über Wasser fahren können.
Wer meint, seinen Speicher besser verwalten zu können, als die modernen VMs dieser Welt, der ist bei Java einfach falsch.

Und wer über das Wasser fahren will, soll lieber ein Boot verwenden.

[Fachwisser]

> J2SE ist weder performant, ressourcenschonend noch hinreichend
> bugfrei, um auf den Desktops anzukommen.

Das J2SE nicht performant ist, ist schlicht eine Lüge. Das mag zu Anfangszeiten von Java so gewesen sein, aber es ist schon seit langem nicht mehr zutreffend. Das ist eine Frage der Kompetenz des Entwicklers ;-)
Man kann auch in Swing ansehnliche und sehr performante UIs entwickeln (siehe z.B. Aerith oder LightZone).

Java auf dem Desktop steht meiner Ansicht nach die fehlende Integration mit dem jeweiligen Betriebssystem im Weg. Da hat sich in letzter Zeit auch ein wenig was getan, wie z.B. der Zugriff auf das Systray etc. Grundsätzlich ist da aber sicher noch der größte Nachholbedarf.
Wenn man nur für eine Plattform entwickelt, dann macht es natürlich Sinn, auch die Tools zu nehmen, die für diese Plattform gemacht sind, wie z.B. die sehr guten Dev-Tools unter OSX oder eben .NET für Windows.
In beiden Fällen hat man eine hohe Integration mit dem Betriebssystem und kann dessen APIs direkt nutzen. Will man in Java entsprechende Programme schreiben, muss man am Ende doch wieder für jede Plattform den Code optimieren - und diese Mühe machen sich einfach die wenigsten.

> Für jede kleine Funktionalität, die über DB- und Filezugriffe
> hinaus geht, muß an die Java-API angebaut werden.

Was genau meinst Du denn für Funktionalität ? Gerade die Vielzahl an Bibliotheken, die es für Java gibt, machen das System sehr interessant.