ZFX + Developia

Ich finde einfach nicht, dass "sie" etwas verkackt haben. Ich finde try-with-resources ein gelungenes leichtgewichtiges Feature. Die Features, die du dir wünscht sind imo viel zu spezifisch und sollten daher nicht in den Java-Sprachstandard. Wenn sich eine bestimmte Bibliothek, die solche Features, wie du sie dir wünscht, liefert, als besonders sinnvoll entpuppt, kann man das immer noch in die Standardbibliothek mit aufnehmen.

Aus meiner Sicht ging es in der Diskussion darum, ob RAII für Java sinnvoll wäre und wieso nur "erste Ansätze" von RAII lediglich via try-with-resources eingebaut wurden. Ich bin der Meinung RAII in Reinform passt nicht in das Konzept von Java und try-with-resources ist eine nette Hilfestellung, um mit zu schließenden Ressourcen umzugehen. Ich habe das Gefühl, dass du mir fehlendes RAII in Java als Nachteil verkaufen willst und dass du den try-with-resources Kram als fehlgeschlagenen Ersatz dafür siehst. Dabei war try-with-resources nie als RAII Ersatz gedacht und ein echter sinnvoller Ersatz ist imo in Java gar nicht möglich.

Ich finde, mein Beispiel war allgemein genug, um eindeutig zu zeigen, dass es sich weder um einen Sonderfall, noch ein spezifisches Feature handelt. Ich finde auch, dass ich ein Konzept vorgestellt habe, das sehr gut in Java passt, und sämtlichen Code sicherer, einfacher und lesbarer macht. Wenn du lieber weiterhin wahlweise lückenhaften unsicheren oder komplexen fehleranfälligen Code schreiben willst, kann ich dir auch nicht helfen.

Das Fehlen von Hilfsmitteln zum Umgang mit Ressourcen und Fehlern ist definitiv ein Nachteil jeder Sprache, auf die ein solcher Mangel zutrifft. try-with-resources ist zweifelsohne ein (lückenhafter) RAII-Ersatz, da es nichts anderes tut, als RAII-Verhalten lokal zu emulieren.

Ich finde dein Beispiel auch gut. Aber ich bin mir immer noch nicht sicher, ob der von dir beschriebene Fall wirklich so oft auftritt. Ressourcen-Zugriffe werden in Java doch oft gekapselt und zu schließende Ressourcen sind nicht selten ein ziemlich nebensächlicher Aspekt von Anwendungen. try-with-resources ist eine Möglichkeit einen Aspekt von RAII nachzuahmen und von diesem Aspekt zu profitieren, aber ein Ersatz ist das genauso wenig wie Generics ein Ersatz für Templates sind.

Chromanoid hat geschrieben:Ressourcen-Zugriffe werden in Java doch oft gekapselt und zu schließende Ressourcen sind nicht selten ein ziemlich nebensächlicher Aspekt von Anwendungen.

Meiner Erfahrung nach sind solche Dinge alles andere als nebensächlich...

Chromanoid hat geschrieben:try-with-resources ist eine Möglichkeit einen Aspekt von RAII nachzuahmen und von diesem Aspekt zu profitieren, aber ein Ersatz ist das genauso wenig wie Generics ein Ersatz für Templates sind.

Mit try-with-resources profitiert man nur in kleinem Rahmen. Das richtig große Problem, nämlich die Transitivität von close(), löst es nicht...

Java Generics lassen wir lieber mal aus dem Spiel, sonst wirds hier noch richtig hässlich :P

Ressourcen-Zugriffe werden in Java doch oft gekapselt und zu schließende Ressourcen sind nicht selten ein ziemlich nebensächlicher Aspekt von Anwendungen.

Was verstehst du denn unter Kapselung von Ressourcenzugriffen? Das Anbieten einer close()-Methode gehört doch zwangsläufig zu jeder gekapselten Ressource. Und wenn diese Ressource nochmal gekapselt wird, muss der Kapselnde auch wieder eine close()-Methode anbieten. Und wenn zwischendurch eine Exception fliegt, muss das auf jeder Ebene behandelt werden. Und wenn außerhalb eine Exception fliegt, muss die gekapselte Ressource irgendwie freigegeben werden. Die Kapselung von Ressourcen ist doch genau das, was im Moment überhaupt nicht vernünftig geht, mangels transitiver Automatismen.

Wo sind Ressourcen nebensächlich? Beschäftigen sich nicht praktisch alle großen Java-Projekte permanent mit Ressourcen? Dateien sind da doch nur der Trivialfall. In jedem Fenstersystem sind so unfassbar viele Ressourcen versteckt, dass man praktisch nur den Überblick verlieren kann (Window Handles, Bitmaps, Graphics / Device Handles). Webanwendungen strotzen nur so vor Datenbankverbindungen und -transaktionen. Ein großer Teil dessen wird im Moment über den dispose()-Mechanismus geregelt. Schlussendlich ist das aber reines Glücksspiel, in der Hoffnung, dass immer rechtzeitig genügend oft dispose() aufgerufen wurde, bevor die Zahl der leakenden Ressourcen überhand nimmt.

Ich selbst bin schon mit einfacher Dateiverwaltung und Memory Mapping in Java in der Situtation gewesen, dass ich den GC ums Verrecken nicht dazu bringen konnte, rechtzeitig die gemappten Bereiche freizugeben. Aber selbst wenn die Ressourcen gerade noch rechtzeitig freigegeben werden, ändert das nichts an der Tatsache, dass in einer dispose()-gesteuerten Ressourcenverwaltung immer ungenutzte Ressourcen rumfliegen werden, obwohl diese eigentlich längst wieder zur Verfügung stehen sollten. Damit leckt ein GC vielleicht unterm Strich keine Ressourcen (wenn wenigstens garantiert würde, dass dispose() bis zum Programmende definitiv aufgerufen wurde), dies gilt dann jedoch allenfalls für den Zeitpunkt, zu dem das Programm vollständig beendet wurde, was für das laufende Programm doch ziemlich uninteressant sein dürfte.

Würde die Ressourcenverwaltung durch den GC in Java funktionieren, dann müsste man niemals close() aufrufen. Alleine die Tatsache, dass trotzdem in jedem guten Beispiel close() aufgerufen wird (je nach Quelle mit mehr oder weniger Lücken durch Exceptions); alleine die Tatsache, dass sich die Sprachentwickler genötigt sehen, try-with-resources einzubauen; das alles zeigt doch, dass Ressourcenverwaltung eben keine Randerscheinung, sondern permanent Thema ist. Damit war es unzweifelhaft Intention der Sprachentwickler, einen RAII-Ersatz zu finden. Und dabei sind sie in meinen Augen kläglich gescheitet. Warum, lässt sich hier in nunmehr unzähligen Posts nachlesen.

@CodingCat: Vieles wird direkt in den Speicher geladen ohne groß ein Handle halten zu müssen, Dependency Injection, JPA, usw. sorgen für immer weniger Kontakt mit dem manuellen Verdrahten von Ressourcen. Und bei GUI kommt man in java und Co. eigentlich immer ohne irgendwelche Ressourcen aus, die man entbinden muss.