Im Original ist die Liste deshalb am Ende noch gedreht worden, das kann ich mir jetzt auch sparen.
Ich hatte ja mal unter Queue Implementations (The Java™ Tutorials > Collections > Implementations) geschaut, und war eigentlich sicher dass es da etwas passendes gäbe, aber es sieht aus, als wäre das (an sich ja triviale) Verhalten, das die EvictingQueue bietet, durch keine Standard-Implementierung abgedeckt 
Warum werden denn nicht einfach alle Elemente ab Index 21 gelöscht, wenn man nur die ersten 20 aufheben will? Da muss man doch nichts kopieren…
Klar, kann man machen. Ich neige aber immer stärker dazu, sowas als „falscher Datentyp“ zu klassifizieren. Wenn ich eine Collection mit begrenzter Größe und FIFO-Verhalten haben will, ist eine Liste einfach der falsche Typ. Die Aufgabe des Kürzens sollte nicht der Klasse aufgebürdet werden, die die Collection benutzt.
Natürlich muss man manchmal Kompromisse machen, aber wenn man Code wie list = list.subList(0, 4) schreibt, sollte man zumindest einen Moment stutzen und sich fragen, ob das wirklich ein Teil des Verhaltens im aktuellen Kontext sein sollte. Wenn man es trotzdem so schreibt, ist das ein Notbehelf, und wenn man z.B. beim Refactorn nicht aufpasst, beißt einen das in den Hintern. Selbst wenn es keine fertige Lösung gibt und ich so ein Verhalten selbst implementieren muss, gehört es eigentlich in die Collection.
Ja natürlich empfiehlt es sich, das als extra Klasse zu kapseln und das Kürzen nicht dort zu machen, wo das Datenobjekt verwendet wird, das sehe ich genauso. Aber dafür jetzt irgendwelche komplizierten Fremd-Klassen ins Projekt zu holen, finde ich übertrieben. Wenn man die betreffende Jar eh schon dabei hat, ist das natürlich etwas anderes. Aber in diesem Fall ist die Datenstruktur ja recht simpel.
Selbst wenn ich eine fremde Datenstruktur dafür nehmen würde, würde ich das u.U. vielleicht sogar noch in eine eigene Klasse kapseln, um die interne Programmierung ohne viele Abhängigkeiten im Projekt einfach ändern zu können.