(Neuigkeiten...) Java ist tot!
-
**
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.
-
Original erstellt von TriPhoenix:
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.Aeh...
das ist aber bloed...
dh ich darf die implementation einer klasse zB nicht um eine logging funktion erweitern.das scheint mir sehr weltfremd.
das sieht eher nach: mhm, so eine situation waere bloed, lass sie uns verbieten
aus.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[/QB]
[/quote]
*lol*
also mir passiert das schon oefters das ich die implementation einer klasse aendern muss. bzw. die klasse durch eine andere mit dem gleichen interface ersetze.bsp fuer C++ waeren policies. sowas hat Java halt nicht, aber trotzdem kann ich die implementation aendern.
nur bloed finde ich, dass das aendern einer implementation den anwendungscode zerstoeren kann.da muss ich als programmierer der klasse ja hoellisch aufpassen, dass ich nicht nachtraeglich features einbaue... (nur weil diese eben ein sofortiges destruieren erfordern)
ne, mal ernsthaft: wie unterscheidest du zwischen 'ist egal wanns zerstoert wird' und 'muss sofort zerstoert werden'
was spricht hier gegen einen dtor? tut er dir weh? ist es verkehrt ressourcen zu schliessen wenn man sie nicht mehr braucht?
ich verstehe die ganze argumentation nicht.
nur weil Java keine dtors hat, braucht man keine?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.
niemand hier behauptet Java sei der letzte dreck.
aber bedenke wofuer java entwickelt wurde!und vielleicht kannst du mir eins erklaeren:
warum habe ich noch nie einen java programmierer getroffen der gesagt haette, dass Java probleme hat. zB weil dtors fehlen oder es dauernd null-reference exceptions hagelt (obwohl es ja garkeine zeiger gibt)...nein, stattdessen wird java hartnaeckig verteidigt - warum?
es ist absolut nicht schwer einen C++ programmierer zu finden der zugibt dass die C++ Template syntax mies ist, oder dass die C++ Standard Library zu klein ist.
-
Original erstellt von Shade Of Mine:
**
Aeh...
das ist aber bloed...
dh ich darf die implementation einer klasse zB nicht um eine logging funktion erweitern.das scheint mir sehr weltfremd.
das sieht eher nach: mhm, so eine situation waere bloed, lass sie uns verbieten
aus.
**Solange du dich selbst drum kümmerst, dass die Klasse von außen nicht anders bedient werden muss, ist egal, was du innen machst.
**
*lol*
also mir passiert das schon oefters das ich die implementation einer klasse aendern muss. bzw. die klasse durch eine andere mit dem gleichen interface ersetze.
**Ja, und du veränderst dabei das Interface nicht. Wie gesagt, solange die Bedienung gleich bleibt, kannst du intern rumwuseln wie du willst.
nur bloed finde ich, dass das aendern einer implementation den anwendungscode zerstoeren kann.
da muss ich als programmierer der klasse ja hoellisch aufpassen, dass ich nicht nachtraeglich features einbaue... (nur weil diese eben ein sofortiges destruieren erfordern)
Du musst genauso aufpassen, dass du die Features nicht so baust, dass die Aufruferklasse die benutzte Klasse fehlbedient.
ne, mal ernsthaft: wie unterscheidest du zwischen 'ist egal wanns zerstoert wird' und 'muss sofort zerstoert werden'
was spricht hier gegen einen dtor? tut er dir weh? ist es verkehrt ressourcen zu schliessen wenn man sie nicht mehr braucht?
ich verstehe die ganze argumentation nicht.
nur weil Java keine dtors hat, braucht man keine?Ist egal wanns zerstört wird --> finalize-Methode. Muss sofort zerstört werden --> ich rufe es auf.
Dtors können nützlich sein, das will ich garnicht verneinen. Ich bin nur der Meinung, dass man wunderbar ohne auskommt. Wenn sie da sind, benutze ich sie gerne, aber sie sind in Java nicht da und das tut nicht weh. Shcon garnicht so, dass es Java zu ner schlechten Sprache macht.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.
**
niemand hier behauptet Java sei der letzte dreck.
aber bedenke wofuer java entwickelt wurde!
**Also ich denke INZWISCHEN wird Java durchaus als generelle Programmiersprache entwickelt, die Ziet der Kaffemaschinen und Applets ist vorbei.
**
und vielleicht kannst du mir eins erklaeren:
warum habe ich noch nie einen java programmierer getroffen der gesagt haette, dass Java probleme hat. zB weil dtors fehlen oder es dauernd null-reference exceptions hagelt (obwohl es ja garkeine zeiger gibt)...
**Weil sie dtors nie gebraucht haben. Und ich habe schon genug Beschwerden über NullPointerExceptions gehört im Esntwicklungsprozess. Fluche selber gerne drüber.
**
nein, stattdessen wird java hartnaeckig verteidigt - warum?
**Ich kann auch gerne C oder Assembelr verteidigen wenn du willst, wir finden sichelrich auch da was
**
es ist absolut nicht schwer einen C++ programmierer zu finden der zugibt dass die C++ Template syntax mies ist, oder dass die C++ Standard Library zu klein ist.**Es ist auch nicht schwer einen Java-Programmierer zu finden, der zugibt dass die Java-Bibliothek teilweise schrecklich aussieht (s.o. irgendwo). Ebenso die Syntax der Collection-Klassen, die bis Java 1.4 wirklich umständlich und eklig ist (was zum Glück in Java 1.5 ausgebügelt wird).
Aber du findest wahrscheinlich auch keinen C++-Programmierer (also so richtige, nicht so gelegenheits-C++-ler wie mich ), der sich beschwert, dass dtors zu unleserlichem Code führen Alles eine Frage der Perspektive.[ Dieser Beitrag wurde am 11.07.2003 um 03:02 Uhr von TriPhoenix editiert. ]
-
passt zwar nicht mehr ganz, aber hier ist der link, den ich weiter vorne mal nachliefern wollte: http://www.rolemaker.dk/articles/evaljava/Evaluating%20Java%20for%20Game%20Development.pdf
Oder wer keine Lust hat, sich das ganze durchzulesen, hier mal ein Ausschnitt:
...John Carmack...spoke about the importance of high level tools and languages in development today. He said that Java may very well be the de facto language for game development in the future. That John Carmack does consider Java a good language is clear from this quote: "We are still working with significant chunks of an existing code base. If I did want to go off and start fresh, I would likely try doing almost everything in Java"
-
klar. In der Zukunft gibts ja im PC auch 30 CPUs mit jeweils 10 GHz Taktrate und 16 TerraByte Speicher...
Ein gescheites auf ein System angepaßtes Programm hätte vielleicht nur 20 CPUs mit 8 GHz und 8 TB Speicher benötigt...
Bist Du übrigens auch so einer, der sich einen 4,8 Tonner gekauft hat, um seine 4 Getränkekisten beim Wocheneinkauf holen zu können? Genau sowas macht Java nämlich. Nur das Java pro Getränkekiste noch 20 Bleiplatten dazupackt und eine Stange von 15 Meter Länge dazunimmt, damit man auch wirklich nicht durch enge Straßen oder über alte Brücken fahren kann.
-
nein ich werd mir die 300 seiten nicht reinziehen
im übrigen hoffe ich nicht daß mein versehen - den threat doch wieder zu beleben
- jemandem magengeschwüre bereitet hat.aber zum thema:
ich bin kein profi, weder in C++ noch in Java, aber ich kann mir echt nicht vorstellen daß die welt der großen anwendungssoftware Java gehört. die VM ist langsam und frisst speicher wie sau. mit kommts aber so vor als käme man bei kleinen sachen schneller zum ziel als mit C++. ich kann mir jedoch nicht vorstellen daß bei umfassenden projekten, die dann wahrscheinlich zig tausende klassen beinhalten, das prinzip noch funktioniert - es gibt auch keine 2 meter lange insekten....
-
Original erstellt von Floh:
ich kann mir jedoch nicht vorstellen daß bei umfassenden projekten, die dann wahrscheinlich zig tausende klassen beinhalten, das prinzip noch funktioniertFrag mal Cengiz.
warum habe ich noch nie einen java programmierer getroffen der gesagt haette, dass Java probleme hat. zB weil dtors fehlen oder es dauernd null-reference exceptions hagelt (obwohl es ja garkeine zeiger gibt)...
Weil es in der Realität keine wirklichen Probleme hierdurch gibt. Die Probleme sind Volkards Hirn entsprungen, nicht der Realität.