(Neuigkeiten...) Java ist tot!
-
Original erstellt von volkard:
[quote]Original erstellt von TriPhoenix:
Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will."wenn" war nicht gefragt. "wann" ist javas problem.[/QB][/QUOTE]
Man kann die Exceptions auch so konzipieren, dass sie bei ihrem Wurf Aufräumarbeiten erledigen.
-
Original erstellt von TriPhoenix:
Ist doch wurst siet wann es das kann. Im Übrigen hat das nichts mit der Sprache zu tun, sondern mit der Implementation der Virtual Machine/des Compilers.war ja nur so als anmerkung auf die feststellung, dass Java das vielleicht irgendwann auch kann.
nunja, schoen wann java das kann. aber als neue optimierung wuerde ich das nicht verkaufen...Exceptions hat Java genauso und man kann Exceptions auch so konzipieren, dass sie etwas aufräumen, wenn man will.
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.Dann wäre die Sprache in der die meisten großen Spiele geschrieben sind auch für nichts großes geeignet. Die Dinger starten auch ewig.
*lol*
vergleich: grosses Spiel in C++ ladet etwa genauso lange wie mittlere IDE in Java.
ich kann als beispiel leider nur JBuilder (4) und Zend Studio 2.5 bieten, mag sein, dass es auch wo etwas schnelleres gibt...aber vergleich mal die startzeit vom VC++ mit dem vom Zend Studio (und dann die features die beide bieten und dann den RAM den sie brauchen)
Wenn es so kritisch ist, sollte man es selbst aufrufen.
mhm... wozu dann generell destruktoren? ich kann ja, wenn ich es loeschen will
foo.release() aufrufen...
-
manche meiner Aussagen, wie zB das mit Carmack waren Sachen aus so nem kleinen Bericht über Java and Games. Ich find nur grad keinen Link, versuch den mal noch wo aufzutreiben (wurde igrngedwann schon mal hier auf dem Forum gepostet). In dem Teil stand auch drin, daß Java ev. mal generell genausoschnell laufen könnte wie C++ und warum. Absolut empfehlenswert sich das durchzulesen (falls ich den Link finde)
Daß Volkard besser programmieren kann als ich will ich btw. gar nicht bestreiten. Aber ich sag halt meine Meinung und selbst wenn sie dumm ist, find ich braucht man nicht gleich beleidigend werden oder abfällig drüber reden. Jedenfalls nicht in einem Fachforum.
dann wuerde ich nicht in Java programmieren, sondern in deutsch.
da stimm ich dir absolut zu
-
Original erstellt von TriPhoenix:
Man kann die Exceptions auch so konzipieren, dass sie bei ihrem Wurf Aufräumarbeiten erledigen.ups, die exceptions. jo, klar. hab ich überlesen.
aber das ist ja ein voll mülliger gedanke.
dann kann ich genauso mit if-orgien 50% des codes mit fehlerbehandlung durchmischen (wie damals in c).
wenn ich die vom system geworfenen exceptions in ihrer funktionalität ändern muß, werd ich unportabel.
wenn ich be jedem wurf aus dem system sofort catchen und umsetzen muß, bin ich nicht viel besser als c.
wenn ich dazu die jetzt noch verbleibenden nichrechtzeitigen destruktoren mit eigenen catch-orgien versehe, bin ich bei c.in c++ wirft man exceptions, wo sie passieren, und fängt sie erst da, wo man siew verarbeiten kann. und in java fängt man sie für jeden dazwischenliegenden scope, wo ein objekt zeitnah destruiert werden muß. ist das nicht ein wenig lachhaft?
-
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.