Warum werden Collections.checkedMap und Freunde nicht häufiger verwendet?

Question

Ich bin kürzlich über den Javadoc für die Collection.checkedMap Familie von Funktionen zum Erstellen dynamisch typsicherer Ansichten der Standard-Collections-Typen gestolpert. Wenn man bedenkt, dass sie zusätzlich zu den Sammlungen eine weitere Sicherheitsschicht hinzufügen, die einen relativ häufigen Programmierfehler diagnostiziert, hätte ich gedacht, dass sie beliebter sein würden. Aus irgendeinem Grund habe ich sie in all den großen Java-Projekten, an denen ich gearbeitet habe, nicht einmal verwendet.

Meine Frage ist dies: Gibt es einen bestimmten Grund, dass Java-Programmierer diese geprüften Wrapper nicht häufiger verwenden? Oder ist es nur Mangel an Nutzen/Mangel an Wissen über ihre Existenz?

BEARBEITEN: Um meine Frage zu klären, enthalten die generischen Versionen der Sammlungen noch typsichere Funktionen. Map 's containsKey, containsValue, remove und get alle arbeiten zum Beispiel auf Object. Meine Hauptfrage ist, dass bei diesem Typ - Unsicherheit - mehr Personen die geprüften Implementierungen nicht verwenden, um Runtime-Typ-Verletzungen zu diagnostizieren.

Answer 1

Diese Klassen sind nur dann wirklich notwendig, wenn man Generika missbraucht (oder nicht benutzt). Sie dupliziert zur Laufzeit Duplikate, die ausreichen sollten, um zur Kompilierungszeit über die Typsicherheitsgarantien der Generics-Engine ausgeführt zu werden. Die Verwendung dieser Methoden ist daher nur im Kontext von API-Designern interessant, die den Benutzern der Bibliothek nicht vertrauen und entweder selbst oder die Benutzer vor den Benutzern schützen möchten, die die Karte nicht ordnungsgemäß verwenden .

Hier ist die Rede kurzer Sinn: Wenn Ihr Code rohen Art Warnungen oder jede unkontrollierte Umwandlung/Typ Warnungen kompiliert ohne, Sie sind garantiert, dass die checked* Methoden, die Sie nicht geben keinen Nutzen; Sie sind nur ein Runtime-Hit.

bearbeiten

Sie scheinen, dass get seit remove, werden den Abschluss, usw. arbeiten auf einem Object, sie sind irgendwie typ unsicher. Sie sind nicht. Keine dieser Methoden speichert ihren Operanden in der Karte, so dass Sie die Typsicherheit der Karte nicht gefährden. Diese Methoden nehmen ein Objekt aus einem Hauptgrund: aus Gründen der Abwärtskompatibilität. Es gab nie eine strenge Anforderung, dass Nachschlagewerke derselben Klasse angehören müssen. Wenn zum Beispiel eine Instanz der Klasse A und eine Instanz der Klasse B einander gleichwertig sein könnten, sollte a in die Map eingefügt werden und dann remove(b)aufgerufen werden, sollte die Zuordnung a entfernen.

Dieses Verhalten musste unterstützt werden, sobald Generika hinzugefügt wurden, um die Abwärtskompatibilität beizubehalten. Daher konnten sie die Schnittstelle nicht auf etwas wie remove(K) aktualisieren, da existierender Code darauf angewiesen sein könnte, eine Zuordnung zu entfernen, die eine Instanz einer vollständig anderen Klasse gegeben hat. Es ist jedoch nicht unsicher, und die Verwendung der geprüften Version der Karte ändert dieses Verhalten nicht im Geringsten.

Answer 2

RETRACT: Die folgende Meinung ist falsch. Abgesehen von der Rückwärtskompatibilität gibt es einige gute Gründe, warum es besser ist, einen Nachschlage-Index zu verwenden.

Es gibt keinen göttlichen Grund, warum diese Methoden Object statt E annehmen müssen. In realen Programmen, wenn ein Nicht-E-Objekt übergeben wird, ist es mit ziemlicher Sicherheit ein Anwendungsfehler.Die E-Version-API wäre in den meisten Situationen besser als die Objekt-Version. Und ich sage, Sun hat hier einen Fehler gemacht. Es gibt kein Problem mit der Rückwärtskompatibilität, da die generische API eine brandneue API ist.

Glücklicherweise würde meine IDE (IntelliJ) mich warnen, wenn ich einen Nicht-E-Typ an diese Methoden übergebe. Die statische Überprüfung wurde weit über die Sprachspezifikation und den Compiler hinaus geschoben.