[JAVA] Ich habe den Unterschied zwischen Collections.emptyMap und Collections.EMPTY_MAP nicht verstanden, und mein Kollege wurde wütend, deshalb schreibe ich ihn hier aus Gründen der Selbstdisziplin auf.

Dieser Artikel ist ein Nachdruck eines Blogposts. https://munchkins-diary.hatenablog.com/entry/2018/11/14/034818

Guten Abend, ich bin ein Java / Scala-Entwickler, der ein JVM-Liebhaber wurde, nachdem er gelernt hatte, wie der C1C2-Compiler funktioniert. (Mein Name ist nicht stabil) Heute (oder gestern) hat mein Kollege darauf hingewiesen, und zum ersten Mal habe ich den Unterschied in der leeren Karte der Sammlungen richtig erkannt, sodass ich ihn hier mit der Bedeutung des nächsten Males veröffentlichen werde. Es ist lange her, dass ich Java zum ersten Mal geschrieben habe, aber es war eine gute Studie, weil ich es überhaupt nicht wusste, obwohl es sehr rudimentär war.

Zunächst aus der Schlussfolgerung

Da das Hauptthema und die Erklärung danach lang sind, werde ich zuerst aus der Schlussfolgerung heraus schreiben. Collections.emptyMap: Sofern der Zeilentyp nicht für den Variablentyp oder den Rückgabewert verwendet wird, wird er in den in der Methode angegebenen Typ umgewandelt und ist typsicher. **Collections.EMPTY_MAP：** Da es sich um ein kanonisches Objekt vom Zeilentyp handelt, gibt es in den Generika keine Typspezifikation und es ist nicht typsicher.

Es ist auch in Oracle's offiziellem JavaDoc richtig beschrieben. https://docs.oracle.com/javase/6/docs/api/java/util/Collections.html#emptyMap%28%29

Im Gegensatz zu dieser Methode bietet das Feld keine Typensicherheit. (Im Gegensatz zu dieser Methode ist das Feld (EMPTY_MAP) nicht typsicher.)

Korrigiert Da @ saka1029 darauf hingewiesen hat, habe ich den Grund für die Typensicherheit aktualisiert

(Siehe die Diskussion später, warum sowohl Methoden als auch Konstanten denselben Zweck haben.)

Gudaguda und ein langes Thema und wie er wütend wurde

Nach dem Mittagessen, als ich an meinem Schreibtisch durch O'Reilis Microservice-Architektur blätterte, erhielt ich eine etwas verstörende Slack-Nachricht von einem ausländischen Kollegen, der in Japan arbeitet (nennen wir es Linus).

Linus: In meinem Profil steht Urlaub, aber bist du noch im Urlaub? Ich: Mein Herz ist endlos im Urlaub ... (Ich lehne mich zurück) Was ist los? La: Nein, dein Code ist so schrecklich, dass du weinen willst ... Ich hei ... La: Glaubst du nicht, es ist Müll, wenn du es selbst siehst? Ich: Ich glaube nicht, dass es ein Problem für Repository ist ... La: Repository Hey ...

Es ist ein Schwertkämpfer in der Mitte. (Zu seinen Ehren verwendet er diesen Wortlaut nur technisch, insbesondere für dumme Fehler und schmutzigen Code, aber es ist normalerweise das sanfteste und humorvollste nette ~~ Geek ~~ Guy)

Um eine Entschuldigung zu finden, ich wusste, dass es einige Probleme gab, weil es die Klasse war, die ich schrieb, als ich im vorigen Semester fuhr, aber ich dachte nicht, dass es ein so schreckliches Design war. Er ist der Anführer des Back-End-Teams und ziemlich beschäftigt. Deshalb habe ich ihn gebeten, mir in seiner Freizeit Feedback zu geben, und er hat sich getrennt. Am Abend, als sich die Arbeit einigermaßen beruhigt hatte, schickte er mir eine weitere Nachricht.

Linus: Hast du irgendwelche Probleme in dieser Klasse bemerkt?

Ich habe so viele Designprobleme aufgeworfen, wie ich mir vorstellen konnte, und auf seine Reaktion gewartet. Aber was von ihm zurückkam, war eine einfachere Antwort.

Nein, wissen Sie, machen Sie zuerst die Grundlagen, bevor Sie eine so große Sache sagen.

ImmutableMap.Builder retvalBuilder = ImmutableMap. <String, T> builder (); Dies ist ein Rohtyp

Kennen Sie den Unterschied zwischen return Collections.EMPTY_MAP; und return Collections.emptyMap ();?

return this.getXXXByIds (Arrays.asList (id)). GetOrDefault (id, null); Sie erwähnen NPE in JavaDoc, aber Sie behandeln Nullen nicht richtig. Warum geben Sie Optional nicht zurück? Erstens sind getOrDefault (x, null) und get (x) gleich.

Was 1 und 3 betrifft, so schämte ich mich, als ich sie sah, rot zu werden. Ich möchte eintreten, wenn es ein Loch gibt. Ich habe keine andere Wahl, als ehrlich zu sein. Ich werde es hier mit der Bedeutung der Reflexion aussetzen. Das Grundlegende ist schließlich, dass ich selbst wiederholt Junioren, die in anderen Ländern arbeiten, in Rezensionen unterrichte. Ich dachte jedoch nicht, dass 2 überhaupt ein Problem ist. Schließlich ist Collections.EMPTY_MAP kanonisch und unveränderlich. Ich dachte, es wäre besser, ein kanonisches Objekt zu verwenden (obwohl es ein Fehler ist), weil es speicherfreundlicher ist, wenn es sich sowieso nicht ändert.

Als ich jedoch JavaDoc las, wurde die Bedeutung klar. Es ist richtig geschrieben, es besteht das Risiko, dass EMPTY_MAP für den Rückgabewert verwendet wird.

Im Gegensatz zu dieser Methode bietet das Feld keine Typensicherheit. (Im Gegensatz zu dieser Methode ist das Feld (EMPTY_MAP) nicht typsicher.)

Ja, es ist nicht typsicher, EMPTY_MAP. Wir Java-Programmierer leben geschützt durch die leistungsstarke Tippfunktion von Java. Programmierer, die atypisch sicheren Code schreiben, sind in der rebellischen Zeit so unreif wie Schüler der Mittelstufe, die unter dem Schutz ihrer Eltern leben und ihre Eltern verachten.

(Es tut mir leid, dass ich zu viel gesagt habe)

Nun, warum gibt es zwei Konstanten und Methoden, obwohl es überhaupt nicht Singlton ist?

Collections.EMPTY_MAP sollte nach den aktuellen Standards eine unnötige Konstante sein, aber ich habe den Grund anhand der veröffentlichten Version verstanden.

** Collections.EMPTY_MAP wurde in Java3 und Collections.emptyMap in Java5 veröffentlicht. ** ** **

Heutzutage setzt sich Generics mit dem Gesicht zusammen, das es schon lange gibt, aber diese Funktion wurde erst kürzlich in Java5 in Java eingeführt. (Als ich Java startete, konnte ich den Typ nicht angeben, also habe ich ihn einzeln umgewandelt.)

Mit anderen Worten, Collections.EMPTY_MAP wurde als kanonisches Objekt ohne Typspezifikation erstellt, da es in einer Zeit erstellt wurde, in der es keine Generika gab. Da Generika jedoch in Java 5 aufgehoben wurden, wurde eine typsicherere Collections.emptyMap-Methode erstellt. Ich würde sagen, dass. Natürlich muss die Standardbibliothek abwärtskompatibel sein, damit Collections.EMPTY_MAP immer noch energisch im Feld läuft.

Aber ehrlich gesagt frage ich mich, ob dies verwendet werden kann. Die Tatsache, dass es nicht als veraltet angegeben ist, hat wahrscheinlich eine beabsichtigte Verwendung, aber ich persönlich weiß nicht, wie ich es heute in Java richtig verwenden soll. Wenn jemand weiß, lass es mich bitte in den Kommentaren wissen.

Zusammenfassung

Die EMPTY_MAP-Konstante der Collections-Klasse ist nicht typsicher und die emptyMap-Methode ist typsicher. Grundsätzlich ist es für Java 5 und höher sicherer, eine leere Map mit der emptyMap-Methode zu erstellen.

Es ist eine kleine Sache, aber ich und Linus haben größten Respekt vor Java und JVMs (und allen Sprachen, Infrastrukturen und Betriebssystementwicklern), daher sollten diese kleinen Fehler wütend genug sein. Ich erkenne das. Es ist schon eine Weile her, seit ich angefangen habe, Java zu schreiben, aber es gibt noch viele Dinge, die ich nicht weiß, und ich denke, dass es eine wirklich lohnende Sprache ist, sie zu lernen.

Übrigens werde ich in Bezug auf die eingangs erwähnte Mikrodienstarchitektur einen weiteren Artikel in meinem Blog und in Qiita schreiben, damit ich ihn zu einem späteren Zeitpunkt veröffentlichen kann.

Es ist eine Zusammenfassung, die nichts mit dem Hauptthema zu tun hat. Dann!