(Neuigkeiten...) Java ist tot!
-
Original erstellt von Shade Of Mine:
ein handle zu einer db will ich so schnell wie moeglich schliessen.
und JA, ich will kein database.Release() aufrufen, denn das vergesse ich vielleicht irgendwann (zB wenn irgendwo bloed ne exception fliegt)
in C++ mach ich das im dtor und gut ist.Nun, man muss natürlich aufpassen und alles zumachen, was man aufmacht
**
*lol*
vergleich: grosses Spiel in C++ ladet etwa genauso lange wie mittlere IDE in Java.
**Hm, wenn Eclipse eine mittlere IDE ist, was solld ann eine "große" IDE sein?
**
mhm... wozu dann generell destruktoren? ich kann ja, wenn ich es loeschen will
foo.release() aufrufen...**Das ist meine Meinung
-
Ich glaube nicht, dass man im Normalfall sehr viele Objekte hat, die Resourcen verkörpern. Wenn man nur C++ kennt, wo jede Heap-Allokation eine Resource ist, kann einem das den Blick schonmal ein wenig vernebeln.
-
Original erstellt von TriPhoenix:
Nun, man muss natürlich aufpassen und alles zumachen, was man aufmachtwillkommen in der steinzeit.
und ressourcenlöcher, synchronisationsprobleme und datenanomalien sind eine naturgegebene eigenschaft von programmen und dürfen zwar gemessen werden, aber ein bekämpfen wäre sinnlos.
-
Original erstellt von TriPhoenix:
Nun, man muss natürlich aufpassen und alles zumachen, was man aufmachtwozu brauche ich dann dtors??
Hm, wenn Eclipse eine mittlere IDE ist, was solld ann eine "große" IDE sein?
ich verwende eclipse nicht. aber wie man so hoert ist es ja eines der ersten java programme die schnell laufen. die gtk GUI soll aber um einiges schneller sein.
hab das nur gehoert. und 62MB sind mir zu gross nur um das zu testen.
also mein Visual Studio ist wesentlich schneller und umfangreicher als JBuildeer 4 und Zend Studio 2.5 -> vielleicht ist eclipse das erste java programm das gut laeuft. ich weiss es nicht.aber alleine das laden eines applets dauert lange (und nein, ich meine nicht das downloaden)
**
mhm... wozu dann generell destruktoren? ich kann ja, wenn ich es loeschen will
foo.release() aufrufen...**Das ist meine Meinung :)[/QB][/QUOTE]
wozu dann exceptions? wozu verbung? wozu OO?
-
Original erstellt von volkard:
willkommen in der steinzeit.
und ressourcenlöcher, synchronisationsprobleme und datenanomalien sind eine naturgegebene eigenschaft von programmen und dürfen zwar gemessen werden, aber ein bekämpfen wäre sinnlos.Nein. Sychroprobleme haben nichts mit Destruktoren zu tun, Datenanomalien auch nicht, wenn man vernünftig programmiert. Ressourcenlöcher bestehen ja auch nicht, wenn du in Java einen Destruktor machst, gehen die Ressourcen ja nicht auf ewig verloren. Ja, es kann sich bis zum Programmende hinziehen im worst case, aber eine vernünftige VM kann das ja durchaus so managen, dass bei Systemengpässen der GC ordnetlich was rauskloppt. Aber dafür kann die Sprache auch nichts.
-
Original erstellt von Bashar:
Ich glaube nicht, dass man im Normalfall sehr viele Objekte hat, die Resourcen verkörpern. Wenn man nur C++ kennt, wo jede Heap-Allokation eine Resource ist, kann einem das den Blick schonmal ein wenig vernebeln.man hat aber _potenziell_ dauernd welche.
nur, weil heute mal da steht:
{
Schueler* s=new Schueler("hans meiser");
...
}
und da nur speicher gebunden wird, heißtr das absolut noch nicht, daß morgen, übermorgen usw nicht die implementierung von Schueler, einer Basisklasse von Schueler oder einem Attribut von Schueler dahingehend geändert wird, daß ein sofortiges Destruieren angesagt wäre.
Daher muß doch jeder halbwegs normale Progger immer für diesen scope alle exceptions catchen, und beim catch s auf 0 setzen, en gc aufrufen und die exceptions wieterwerfen.
oder jeder, der Schueler benutzt, muß sich in die Schueler.java in nen kommentar eintragen, daß er bescheid kriegt, sobald sich dahingehend was ändert.
ich halte beides für nicht gangbar. merke: große projekte nicht in java, das wird nix.
-
**
aber alleine das laden eines applets dauert lange (und nein, ich meine nicht das downloaden)
**Bring deinem Betriebssystem bei, die Java VM permanent und abrufbereit im Speicher zu halten, dann dauert ein Applet auhc nicht mehr lange. Den Binary-Loader darf das OS hja auch im Speicher halten
wozu dann exceptions? wozu verbung? wozu OO?
Für strukturierte Fehlerbehandlung anstatt if-Orgien.
Für strukturierte Programmierung und wiederverwendbaren Code, zur Abstraktion von Schnittstelle und Implementation.
Dito.
Destruktoren braucht man nicht unbedingt dafür (IMHO
).
-
Original erstellt von volkard:
**Daher muß doch jeder halbwegs normale Progger immer für diesen scope alle exceptions catchen, und beim catch s auf 0 setzen, en gc aufrufen und die exceptions wieterwerfen.
**Nein, da reicht auch ganz außen den gc aufrufen. Sobald der Scope von s vorbei ist, landet das Objekt automatisch auf der Abschussliste und das passiert sobald irgendwo innerhalbeine Exception geworfen wird und die in dem Scope nicht gefangen wird. Mal davon abgesehen ist das Aufrufen des GC sowieso nur ein Hint und damit nicht wirklcih von belang.
-
Original erstellt von TriPhoenix:
Nein. Sychroprobleme haben nichts mit Destruktoren zu tun, Datenanomalien auch nicht, wenn man vernünftig programmiert. Ressourcenlöcher bestehen ja auch nicht, wenn du in Java einen Destruktor machst, gehen die Ressourcen ja nicht auf ewig verloren. Ja, es kann sich bis zum Programmende hinziehen im worst case, aber eine vernünftige VM kann das ja durchaus so managen, dass bei Systemengpässen der GC ordnetlich was rauskloppt. Aber dafür kann die Sprache auch nichts.syncro hat aberwohl was mit dtoren zu tun. ich mach die datenbank auf. exception fliegt. benutzer sagt: "probiers nochmal, diesmal hab ich ne diskette drin". ich mach datenbank wieder auf. schreibe sachen. alte datenbank geht zu (dtor durch gc ausgelöst). sie schreibt die alten änderungen. hurra, daten sind kaputt.
-
Original erstellt von TriPhoenix:
Nein, da reicht auch ganz außen den gc aufrufen.kommst aber doch nicht immer nach ganz außen.
-
Original erstellt von volkard:
syncro hat aberwohl was mit dtoren zu tun. ich mach die datenbank auf. exception fliegt. benutzer sagt: "probiers nochmal, diesmal hab ich ne diskette drin". ich mach datenbank wieder auf. schreibe sachen. alte datenbank geht zu (dtor durch gc ausgelöst). sie schreibt die alten änderungen. hurra, daten sind kaputt.Wieso ist die Datenbank dann kaputt? Dann ist ausschließlich die Datenbank nicht korrekt programmiert, für sowas kann man in der Datenbank genug Methodik implementieren, die transaktionen ganz oder garnicht ausführt. Eine Datenbank die z.B. nicht abkann, dass eine Verbindung von Client x aufgebaut wird, dann ein Client y Änderungen macht und dann Client x die Verbidnung einfach schließt und danndie Datenbank inkonsistent wird, hat was falsch gemacht. Ansonsten: Man muss ja nicht für jede Wurst die Datenbank zumachen.
-
Original erstellt von volkard:
Original erstellt von TriPhoenix:
Nein, da reicht auch ganz außen den gc aufrufen.
kommst aber doch nicht immer nach ganz außen.Ich meine mit außen die Äußerste Stelle, die diese Operation betrifft. Außerdem wie gesagt, ein gc-Aufruf kann man sich auch meistens sparen.
[ Dieser Beitrag wurde am 11.07.2003 um 01:31 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
Wieso ist die Datenbank dann kaputt? Dann ist ausschließlich die Datenbank nicht korrekt programmiert, für sowas kann man in der Datenbank genug Methodik implementieren, die transaktionen ganz oder garnicht ausführt. Eine Datenbank die z.B. nicht abkann, dass eine Verbindung von Client x aufgebaut wird, dann ein Client y Änderungen macht und dann Client x die Verbidnung einfach schließt und danndie Datenbank inkonsistent wird, hat was falsch gemacht. Ansonsten: Man muss ja nicht für jede Wurst die Datenbank zumachen.dann nimm keine teure datenbank, sondern ein schlichtes logfile.
-
Original erstellt von volkard:
dann nimm keine teure datenbank, sondern ein schlichtes logfile.Okay, ich frage mich noch immer, wie das Logfile dabei kaputt gehen soll. Öffnen ist ne harmlose Aktion, schließen erst recht. Und da der eine Teil bei dem die Exception fliegt nichts anderes tut, können die Daten nicht kaputt gehen.
-
Original erstellt von TriPhoenix:
**Ich meine mit außen die Äußerste Stelle, die diese Operation betrifft. Außerdem wie gesagt, ein gc-Aufruf kann man sich auch meistens sparen.
**minstestens in der funktion, denn sich über funktionsgrenzen den mist zu merken, ist unzumutbar. also pro funktion, wo ein objekt sterben könnte, ein catch und ein dtor-aufruf für jedes objekt.
und übrigens wieder zum steinzeitlichen "single entry/single exit". sonst würden mal schnell hingepfefferte returns schaden anrichten.
und zwar, wie ich weiter oben erläuter habe, weil es möglich ist, daß sich die implementierung einer benutzen klasse ändert.ok, sagst, es ist in java einfach so, daß objekte lange leben dorfen, auch nach ihrem offiziellen tod.
wie sorgste genau dafür, daß das logfile, das noch lebt, das logfile, das jetzt aufgeht, nicht zerstört? ne globale liste aller files? ist wohl entschieden zu teuer. aber wie kann sonst ein sich öffnendes file das noch offene zwingen, zu flushen? sollten files immer sofort flushen? nee, zu teuer. wie also?
-
Original erstellt von TriPhoenix:
Okay, ich frage mich noch immer, wie das Logfile dabei kaputt gehen soll. Öffnen ist ne harmlose Aktion, schließen erst recht.schließen bedeutet, daß der schmonz geschrieben wird, der noch im ram war. und natürlich ist es fatal, wenn ne schreibung passiert und die andere schreibung an die selbe stelle schreibt, statt dahinter.
-
Original erstellt von volkard:
**minstestens in der funktion, denn sich über funktionsgrenzen den mist zu merken, ist unzumutbar. also pro funktion, wo ein objekt sterben könnte, ein catch und ein dtor-aufruf für jedes objekt.
**Wozu, ob du nun wie du meinst selber das Objekt auf NULL setzt oder es ausm Scope fliegt ist kekskram. Und die paar Ressourcen die wirklich eine spezielle Behandlung wie eine Datenbank schließen beinhalten, kann man immernoch try-catch-finally oder auch nur try-finally bauen.
**
und übrigens wieder zum steinzeitlichen "single entry/single exit". sonst würden mal schnell hingepfefferte returns schaden anrichten.
**Was damit wegfällt.
**
und zwar, wie ich weiter oben erläuter habe, weil es möglich ist, daß sich die implementierung einer benutzen klasse ändert.
**Die Implementierung einer Klasse darf sich nur innerhalb dessen Ändern, was ihre Schnittstelle preisgibt. Wenn die Schnittstelle nicht von Anfang an sagt, dass unbeidngt an noch etwas Destruktorartiges zu tun ist, darf sich diese Tatsache auch nicht ändern. Ansonsten köntne man genauso gut anfangen, die Bedeutung von Methoden in der Implementation zu ändern, das macht auch jedes benutzende Programm kaputt
ok, sagst, es ist in java einfach so, daß objekte lange leben dorfen, auch nach ihrem offiziellen tod.
wie sorgste genau dafür, daß das logfile, das noch lebt, das logfile, das jetzt aufgeht, nicht zerstört? ne globale liste aller files? ist wohl entschieden zu teuer. aber wie kann sonst ein sich öffnendes file das noch offene zwingen, zu flushen? sollten files immer sofort flushen? nee, zu teuer. wie also?Okay, ich sehe ein, mti nem ausstehenden write-Vorgang wirds eklig. Dann halt einen try-finally block um alles, was sich ums Logfile kümmert
So stellst du sicher, dass nie zweimal dasslebe Logfiles auf ist, genauso wie mit Destruktoren.[ Dieser Beitrag wurde am 11.07.2003 um 01:46 Uhr von TriPhoenix editiert. ]
-
Original erstellt von TriPhoenix:
Und die paar Ressourcen die wirklich eine spezielle Behandlung wie eine Datenbank schließen beinhalten, kann man immernoch try-catch-finally oder auch nur try-finally bauen.verdammt, lies meine postings!
du kannst nicht vorher wissen, ob die klasse Schueler sofort destruiert werden muß. deswegen mußte konsequent alle objekte schützen.und übrigens wieder zum steinzeitlichen "single entry/single exit". sonst würden mal schnell hingepfefferte returns schaden anrichten.
Was damit wegfällt.eben nicht.
Die Implementierung einer Klasse darf sich nur innerhalb dessen Ändern, was ihre Schnittstelle preisgibt. Wenn die Schnittstelle nicht von Anfang an sagt, dass unbeidngt an noch etwas Destruktorartiges zu tun ist, darf sich diese Tatsache auch nicht ändern. Ansonsten köntne man genauso gut anfangen, die Bedeutung von Methoden in der Implementation zu ändern, das macht auch jedes benutzende Programm kaputt
kann java das in code ausdrücken? oder mußte kommentare lesen? und sind klassen wirklich unveränderlich?
Okay, ich sehe ein, mti nem ausstehenden write-Vorgang wirds eklig. Dann halt einen try-finally block um alles, was sich ums Logfile kümmert
So stellst du sicher, dass nie zweimal dasslebe Logfiles auf ist, genauso wie mit Destruktoren.na, du fängst an, zu kooperieren. ok.
try-finally also. um jeden block, der ein lokales objekt enthält, das das problem mit dem ausstehen write HABEN KÖNNTE. oder mach mir nochmal enbau klar, wie das war mit klasen, die man nie im leben wieder verändert, weil die schnittstelle feststeht. nichtmal designfehler ausbügeln? sowqs soll vorkommen.
-
Original erstellt von volkard:
**verdammt, lies meine postings!
du kannst nicht vorher wissen, ob die klasse Schueler sofort destruiert werden muß. deswegen mußte konsequent alle objekte schützen.
**siehe Unten von wegen Klasseninterface
**
kann java das in code ausdrücken? oder mußte kommentare lesen? und sind klassen wirklich unveränderlich?try-finally also. um jeden block, der ein lokales objekt enthält, das das problem mit dem ausstehen write HABEN KÖNNTE. oder mach mir nochmal enbau klar, wie das war mit klasen, die man nie im leben wieder verändert, weil die schnittstelle feststeht. nichtmal designfehler ausbügeln? sowqs soll vorkommen.**
Nein, das drückt man in Javadoc-Kommentaren aus. Und ich meine es stand irgendwo in der Spezifikation, dass Methoden so nicht verändert werden dürfen, sprich die semantik erhalten bleiben muss. Nein, auf solche Art darf man Designfehler leider nicht ausbügeln, deswegen hat leider die Java-Bibliothek noch immer einige absoluten Hässlichkeiten. Man muss das alte Interface erhalten, darf es nur erweitern. Das macht übrigens nicht nur Java so, sowiet ich weiß, es gibt auch irgendwo in der Gegend von COM oder so dieses Prinzip.
Edit: in der Spec stehts nicht direkt, dort betrifft nur das Interface aus Sprachsicht. Trotzdem ist ein solches Ausbügeln genauso ausbügeln wie die Implementation einer Methode massiv zu ändern, weil ein Designfehler auftritt. Das kann auch Quellcode unbrauchbar machen.
[ Dieser Beitrag wurde am 11.07.2003 um 02:07 Uhr von TriPhoenix editiert. ]
-
@ Volkard: Bleib du doch einfach bei C++, wenn du dich nicht mit Java anfreunden kannst. Wir bleiben halt bei Java.
...um auf das ursprüngliche Thema ("Java ist tot!") zurückzukommen:
Java mag nicht perfekt sein und aus Volkards Sicht ist es der letzte Dreck, trotzdem hat Java eine blendende Zukunft aus dem einfachen Grund, dass es sehr sehr viele Leute gibt, die Java nutzen und Java für gut halten. Für Volkard sind das alles Nubes und andere Idioten, aber das macht nichts. Global gesehen ist Volkards Meinung irrelevant. Sie hat ja nichtmal Auswirkungen auf die Javaprogrammierer in diesem Forum.