remove in for

[krgewb]

Ist das erlaubt oder schreit es nach Exception?

for (Map.Entry<String, Long> entry : mappingUuidAndTsOfHeartbeat.entrySet()) {
    String uuid = entry.getKey();
    Long tsOfHeartbeat = entry.getValue();
    long diffInMilliseconds = now - tsOfHeartbeat;
    if (diffInMilliseconds > ttl) {
        mappingUuidAndTsOfHeartbeat.remove(uuid);
    }
}

 

[Robert Zenz]

Mein erster Instinkt war dass eine Exception geworfen wird, tatsaechlich ist das Ergebnis aber undefiniert. Java 8 Map.entrySet():

Returns a Set view of the mappings contained in this map. The set is backed by the map, so changes to the map are reflected in the set, and vice-versa. If the map is modified while an iteration over the set is in progress (except through the iterator's own remove operation, or through the setValue operation on a map entry returned by the iterator) the results of the iteration are undefined. The set supports element removal, which removes the corresponding mapping from the map, via the Iterator.remove, Set.remove, removeAll, retainAll and clear operations. It does not support the add or addAll operations.

Hervorhebung von mir.

 

[Robert Zenz]

Und ich darf wieder auf meine Wiederholung zum Thema Boxing verweisen.

 

[httpdigest]

Hat weniger mit "sauber" zu tun, als vielmehr mit "dass es überhaupt erstmal funktionieren sollte".
Also, seine Lösung ist ja nicht "unsauber", sondern einfach komplett falsch bzw. würde nicht funktionieren.
"Unsaber" wäre für mich: "Es funktioniert zwar, erfüllt also die Anforderungen, ist aber im Sinne der Wartbarkeit und des Verständnisses schlecht"

 

[KonradN]

Es tritt eine Exception auf. Die ApiDoc ist an der Stelle ungenau, weil das nicht erwähnt wird. ... Das kommt wiederum dir zugute, weil du deine Antwort nach besten Wissen geschrieben hast, also nicht bewusst Unsinn verbreiten wolltest.

Auch wenn es vermutlich wenig Sinn macht, das hier im Detail zu vertiefen:
Es gibt klare Anforderungen, was bei einer Implementation von Java (Compiler, JVM, Framework) erfüllt sein muss und es gibt diesbezüglich sehr umfangreiche Tests von Oracle, die dies überprüfen.

Wenn ein Verhalten nun nicht definiert wurde, dann ist das Ergebnis schlicht undefiniert. Eine Implementation könnte eine Exception werden und eine andere könnte ohne Exception auskommen. Und ich habe keinen Zugriff auf diese Testsuite, daher kann ich nicht nachsehen, ob/was hier getestet wird. Aber die Dokumentation stimmt in der Regel sehr genau überein und die Aussage sollte daher mit der Testsuite überein stimmen.

Die Chance ist aber sehr hoch, dass alle üblichen Implementationen hier eine ConcurrentModificationException werfen werden.

 

[httpdigest]

Hier ist es aber ein bisschen Grauzone, weil es nicht direkt einen Übersetzungsfehler gibt, sondern erst später zur Laufzeit.

Naja, das ist keine Grauzone. Nicht jeder Fehler in einem Programm ist immer gleich ein Übersetzungs-/Compilerfehler. Nur die, die eben nicht der Grammatik oder Typisierung der Sprache entsprechen, können hier gefunden werden. Alles andere (und ich würde fast sagen, "das meiste" - z.B. NPEs) ist erst ein Fehler zur Laufzeit.
Und einige Sprachen haben ja noch nicht mal einen Übersetzungsschritt (JavaScript, Python, ...). Würdest du dort sagen, dass man mit solchen Sprachen gar keine Fehler produzieren kann?