(Neuigkeiten...) Java ist tot!
-
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.
-
@FTK
Yo, John Carmack hat auch sicher keine Ahnung und Java ist einfach langsam und unbrauchbar. Übrigens waren es John Carmack und die anderen Leute von idSoftware die Doom als eines der ersten Spiele im damals als furchtbar langsam geltenden C (statt Assembler) geschrieben haben.Ich werd nach diesem Posting ab sofort nix mehr zu dem Thema sagen, weil's mir echt auf'n Sack geht. Keiner braucht Java programmieren und ich geb zu daß in zeitkritischen Programmen C++ nach wievor (vielleicht auch für immer) besser geeignet ist. Was mich ankotzt ist die ständige Negativität gegenüber Java, als ob's die letzte Sprache wäre und alle Vorurteile werden immer wieder abgefeuert: langsam, speicherfressend, umständlich, nur für nubes.. das sich zB die Performance-Probleme bei jeder neuen VM-Version verringern, wird natürlich nicht wahrgenommen oder gar erwähnt. Oder daß Java erst 7 Jahre alt ist und noch lang nicht "erwachsen" und ausgereift ist und man vielleicht mal noch etwas schauen sollte, was die Zukunft noch so bringt, bevor mal entültige Urteile abgibt.
-
Öhm, hier wird immer gesagt "Java ist scheiße, weil es keine Destruktoren hat". Moment mal. Die einzige Sprache, die Destruktoren hat, ist C++. Damit müßte ja logischerweise C++ die Erfüllung für OO sein. LOL.
Man ändert einfach eine simple Schüler-Klasse nicht hinter den Kulissen so ab, dass Clientcode auf jeden Fall eine close-Methode aufrufen müßte. Fertig. Nur weil man in C++ Anwendern in jeglicher Form hinter den Kulissen verschandelten Code vorsetzen kann, ohne dass sie es merken, heißt das nicht, dass das auch gut so ist. Mit OO hat das schon gleich gar nichts zu tun.
Im übrigen find ich finalizer doof.
-
Original erstellt von Bashar:
Öhm, hier wird immer gesagt "Java ist scheiße, weil es keine Destruktoren hat". Moment mal. Die einzige Sprache, die Destruktoren hat, ist C++. Damit müßte ja logischerweise C++ die Erfüllung für OO sein. LOL.was ne scheiße. java hat destruktoren. wie ich das kinde nenne, ist doch egal, es ist code, dem ich sagen kann, daß er automatisch aufgerufen wird, wenn das objekt stirbt. problem an den java-destruktoren ist nur, daß sie nicht sofort aufgerufen werden.
perl hat auch destruktoren, die sofort aufgerufen werden. wie kommste drauf, daß c++ die einzige sei, die destruktoren hat.
ich mag nicht mit php arbeiten, weil es da keine destruktoren gibt. das sollte in php5 anders sein. dann werd ich php vermutlich mögen.
nicht alle sprachen brauchen überhaupt destruktoren. wenn es unaufwendig ist, ne funktion drumzubauen, die das zu destruierende objekt hält und dann killt, dann ist das für auto-objekte auch fein. und für objekte in containern reicht ne close-methode.Man ändert einfach eine simple Schüler-Klasse nicht hinter den Kulissen so ab, dass Clientcode auf jeden Fall eine close-Methode aufrufen müßte. Fertig.
in spielzeugsprachen darf man das nicht.
aber stell dir doch mal vor, man dürfte das ohne die stabilität des programms auch nur zu gefährden! wäre das nicht toll? es ist toll, und ich verlange, daß man das darf.Mit OO hat das schon gleich gar nichts zu tun.
das sagt ja auch keiner.
-
Original erstellt von Gregor:
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.klar isses schwer, nubes was beizubringen. besondert dann, wenn unter ihnen auch ein paar idioten sind, die politische argumente vor leicht einsehbare technische argumente setzen.
-
Original erstellt von Gregor:
**[quote]
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.**[/QUOTE]
nee.
weil die ganzen java-progger, die nicht über den tellerrand schauen können, das problem gar nicht begreifen. sie kennen es halt nicht anders.
und die, die es begreifen, wechseln sofort zu ner vernünftigen sprache.
folglich haste keine beschwerden von java-proggern.
außer von einigen, die durch den job dazu gewzwungen sind, aber durch irgendwelche unglücklichen umstände schon mehr wissen, als der java-progger wissen sollte.
-
Original erstellt von volkard:
java hat destruktoren. wie ich das kinde nenne, ist doch egalJava hat Finalizer. Nein das ist nicht egal. Destruktoren werden aufgerufen, wenn das Objekt den Scope verläßt, Finalizer wenn das Objekt collectet wird.
perl hat auch destruktoren, die sofort aufgerufen werden. wie kommste drauf, daß c++ die einzige sei, die destruktoren hat.
Was für ein Speichermanagement hat Perl? Destruktoren machen eigentlich nur Sinn in Sprachen ohne Garbage Collection. Man könnte den Begriff des Destruktors auch sinnvoll auf Mechanismen mit Referenzzählung ausweiten, das dürfte eher auf Perl zutreffen. Ist immernoch die Minderheit der Sprachen.
**
aber stell dir doch mal vor, man dürfte das ohne die stabilität des programms auch nur zu gefährden! wäre das nicht toll? es ist toll, und ich verlange, daß man das darf.**Verlangt irgendwer von dir, dass du in Java programmierst? Wenn du C++-like verdrahtet bist, bitte; andere haben andere Programmierstile.
[ Dieser Beitrag wurde am 11.07.2003 um 12:30 Uhr von Bashar editiert. ]
-
Original erstellt von Bashar:
Verlangt irgendwer von dir, dass du in Sprachen programmierst, wo das nicht geht? Jeder hat so seinen Stil ... wenn du so mit C++ verdrahtet bist, bitte.das argument kannste auch zu später bindung, zum operatorenüberladung, zu templates, zu zeigern sagen.
daher ungültiger allgemeinplatz.
-
Warum ungültig?
-
Original erstellt von Bashar:
Warum ungültig?weil man ohne das alles die sprache entweder komplett in die tonne treten muß, oder andere erweiterungen machen muß. aber auch nicht jeder, will aus java gleich lisp machen.
-
Original erstellt von Bashar:
Was für ein Speichermanagement hat Perl?referenzzähler, genau, wie du angenommen hast.
-
Original erstellt von Bashar:
Ist immernoch die Minderheit der Sprachen.und?
ich behaupte, daß die intelligentesten 5% der menschheit in der minderheit sind. sind sie deshalb schlechter?