List.of (...) oder Collections.unmodiableList ()

Dies ist nicht wirklich ein guter Vergleich, weil diese Ansätze verschiedene Dinge tun:

• Collections::unmodifiable... erstellt eine nicht änderbare Ansicht. Es ist nicht unveränderlich, da es sich ändert, wenn Sie die ursprüngliche, unterstützende Sammlung ändern ( list in Ihrem Beispiel).
• ...::of erstellt dagegen eine unveränderbare Kopie. Das Ändern der ursprünglichen Liste hat keine Auswirkungen.

In einer Performance-Ansicht ist es offensichtlich, dass die Erstellung des nicht änderbaren Wrappers billiger ist, da nur eine Instanz mit einem einzelnen Feld erstellt wird. Die neuen Factory-Methoden erstellen mindestens ein Objekt, das möglicherweise von einem Array unterstützt wird (wenn Sie drei oder mehr Elemente haben), in das es kopiert werden muss.

Der Zugriff auf die neuen unveränderbaren Sammlungen könnte schneller sein, aber dies müsste ein Benchmark sein.

Aber die Korrektheit übertrifft die Leistung. Was brauchst du ? Wenn Sie eine unveränderliche Kopie benötigen, verwenden Sie die neuen Methoden (oder Guavas Immutable... , die ich bevorzugen würde). Wenn Sie etwas unveränderlich benötigen, verwenden Sie unmodifiable... und werfen Sie das Original weg (und stellen Sie sicher, dass es so bleibt). Wenn Sie eine Ansicht benötigen, die der Aufrufer nicht bearbeiten kann, verwenden Sie unmodifiable... .

Laut JEP 269 (Convenience-Factory-Methoden für Sammlungen) :

  

Ziele

     

Stellen Sie statische Factory-Methoden für die Sammelschnittstellen zur Verfügung   Erstellen Sie kompakte, nicht änderbare Sammlungsinstanzen. Die API ist   bewusst minimal gehalten.

     

Nicht-Ziele

     

• Es ist kein Ziel, einen allgemeinen "Sammelerzeuger" zur Verfügung zu stellen.   Diese Funktion ermöglicht es beispielsweise dem Benutzer, die Sammlung zu steuern   Implementierung oder verschiedene Merkmale wie Wandelbarkeit, erwartet   Größe, Ladefaktor, Parallelitätsebene und so weiter.

  

• Es ist kein Ziel, leistungsstarke, skalierbare Sammlungen zu unterstützen   mit beliebigen Zahlen von Elementen. Der Fokus liegt auf kleinen Sammlungen.

  

• Es ist kein Ziel, nicht änderbare Sammlungsarten bereitzustellen. Das ist,   Dieser Vorschlag stellt das Merkmal der Nichtmodifizierbarkeit nicht in Frage   das Typsystem, obwohl die vorgeschlagenen Implementierungen tatsächlich sind   nicht änderbar.

  

• Es ist kein Ziel, "unveränderlich persistent" oder "funktional" zu liefern   Sammlungen.